Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sort_pub_dependencies should consider non-pub as different #59714

Open
FMorschel opened this issue Dec 13, 2024 · 3 comments
Open

sort_pub_dependencies should consider non-pub as different #59714

FMorschel opened this issue Dec 13, 2024 · 3 comments
Labels
area-analyzer Use area-analyzer for Dart analyzer issues, including the analysis server and code completion. P4

Comments

@FMorschel
Copy link
Contributor

I believe sort_pub_dependencies should behave similarly to directives_ordering where if I have:

dependencies:
  provider: ^6.0.5
  my_package:
    path: /path/to/package
  other:
    git:
      url: git://github.com/My-Company/my.git
      ref: main

For this, I'd say I'd have three different "spaces". One for pub, one for git and another for path. In my company, we have some internal packages and having that triggering for sorting them all together is a bit weird IMO considering (the directives_ordering logic and) the amount of space required for path dependencies and pub dependencies.

@FMorschel FMorschel added the area-analyzer Use area-analyzer for Dart analyzer issues, including the analysis server and code completion. label Dec 13, 2024
@FMorschel
Copy link
Contributor Author

Also, similarly to dart: imports, I'd like flutter packages (with sdk entry) to be separate as well. So possibly any of the options could be separate.

dependencies:
  flutter:
    sdk: flutter
  flutter_localizations:
    sdk: flutter

@bwilkerson
Copy link
Member

The directives_ordering behavior is based on the Dart Style Guide, but there is no similar style advice for pubspec files, so we had to choose an ordering.

Which ordering is best depends on what you're trying to do. My guess is that most of the time users are trying to find information about a package (usually to change the version constraints), in which case having the package names be alphabetized optimizes the search process and hence makes the most sense.

What action are you trying to perform that would be better served by having them grouped by the way in which the packages are located?

@FMorschel
Copy link
Contributor Author

Mostly for me, it would be the same (versioning of pub packages), but for path packages, we usually don't keep moving things around (same for git and such) so they currently clutter the list of pub packages with multiple lines that, at least for me, make it harder to read the names/find the packages coming from pub.

Moving them out of place would make it clearer for us to read the names of packages. But since we are moving things separately, I felt like separating them with their types would be good so we know where they are along the file easily. But it would also feel a bit more at home considering we also have separations for sdk imports, (pub) package imports and local declarations.

Inside those separations, I agree we could follow the same logic for alphabetical sorting.

@scheglov scheglov added the P4 label Dec 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-analyzer Use area-analyzer for Dart analyzer issues, including the analysis server and code completion. P4
Projects
None yet
Development

No branches or pull requests

3 participants