Dart-code: sort imports.

[bsutton]

Effective dart generates a lint for the sort order of imports.

It would be nice if dart-code added imports according to the sort rules of effective dart.

dart imports
package imports
relative imports

Each of the above sorted alphabetically.

[DanTup]

This should already exist - there's an Organize Imports command in the command palette/Source Action menu.

You can also set it to run on-save if you want, with this setting:

"editor.codeActionsOnSave": {
    "source.organizeImports": true
},

Let me know if this doesn't work or isn't what you wanted!

[bsutton]

Is there any documentation on these settings?

It does what I want but I think the quick fix should always apply the
organize option by default.
Possibly have a way to turn it off but on by default.

On Tue, 26 May 2020 at 01:07, Danny Tuppeny [e-mail]
wrote:

This should already exist - there's an Organize Imports command in the
command palette/Source Action menu.

You can also set it to run on-save if you want, with this setting:

"editor.codeActionsOnSave": {
"source.organizeImports": true},

Let me know if this doesn't work or isn't what you wanted!

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Dart-Code/Dart-Code/issues/2489#issuecomment-633614614,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAG32OCXXFNJJJR35YEAENTRTKCUTANCNFSM4NIGDEQA
.

[DanTup]

The command to organize imports, and the setting to run on-save are both VS Code features. I can't find any info on them, though it was mentioned in the release notes:

https://code.visualstudio.com/updates/v1_23#_run-code-actions-on-save

Possibly have a way to turn it off but on by default.

Unfortunately (because it's VS Code functionality) there's no great way of doing this without overriding VS Code settings (which causes issues and complaints, because the Settings UI doesn't make it clear why settings are behaving differently to what VS Code shows).

I think the quick fix should always apply the organize option by default.

To clarify - are you seeing imports being inserted by the language server incorrectly? Usually it does insert them in the correct place and shouldn't require manual sorting (I just had a quick test of this, and it seems t do so for me). If you have an example of this failing, it may be worth opening an SDK bug.

[bsutton]

So I dug a bit deeper.
It looks like the quick fix does add them in the right order.

I think the problem is the package vs relative path issue.

Doing some experimentation it looks like if the import is in or below the same folder then the 'relative import' is offered.
If the path is above the current folder and the relative path would contain '..' then only the package import is offered.
So I would suggest that the required change is to offer the relative import provided that the import is in the same project.

This would need to check for a couple of scenarios.
If the source file is under lib then any file also under lib should be offered as relative.
If the source file is under example then any file under example should be offered as relative.
Same for test.
I'm not certain about bin. I'm guessing that you are not meant to have a folder structure under the bin directory just a set of libraries each with their own 'main'.

[DanTup]

So I would suggest that the required change is to offer the relative import provided that the import is in the same project.

Based on https://github.com/dart-lang/sdk/issues/32916#issuecomment-634091912 here should be quick-fixes for both kinds of imports now. I don't think there's a clear preference for one or the other, so it's currently up to users to pick the one they want.

That case is also tracking auto-imports though, which I think will need a preference from the user (whether it's by lints, or copying existing imports, or something else), which I think would then allow the "preferred" one to appear above the other (or even as the only option).

So I think we can close this as a dupe of https://github.com/dart-lang/sdk/issues/32916 - I don't think there's any VS Code work to do - but let me know if you think that's not the case. Thanks!

[kinex]

In my opinion the current "organize imports" is not useful. I prefer this ordering:

1. dart imports
2. flutter imports
3. Plugins grouped by plugin author (from pub.dev), for example plugins from flutter.dev in one group (and prioritize flutter.dev as the first group)
4. imports from my own (local) packages grouped by package
5. imports from this package

Each section sorted alphabetically. It would be great if that sorting could be automated, currently I am doing this manually

[DanTup]

Sorting is handled by the SDK, so any changes would need to be requested at https://github.com/dart-lang/sdk.

I'm not sure if sorting by "invisible" metadata like plugin author is possible (if you've never run pub get they wouldn't be known) or generally desirable (the list would always look like it's sorted badly, since the author isn't visible in the source).

[bsutton]

I would have to agree that sorting by meta data doesn't make sense.

I think sorting is about letting you visually scan the list and easily find an import.
For this to work it needs to be alphabetical.

[kinex]

Ok even if we forget that "sorting by author" (which can be read also "I want to see all Firebase imports listed in one group"), this would be better compared to current sorting:

1. dart imports
2. flutter imports
3. plugin imports
4. imports from my own (local) packages grouped by package
5. imports from this package

The two most important things I want to see from the import list are these:
1) Which pub.dev plugins are used here?
2) Which local (my own) packages are referenced (outside current package)? Sometimes looking at this list points you out an architecture issue in your app.

Grouping Flutter imports and plugin imports together makes as much sense as grouping Dart imports together which is already done. Basically same for my own plugins.

Currently the list is a mess of my own plugins, Flutter plugins and 3rd party plugins. I don't know how that is useful.

What comes to relative imports, at least earlier it was recommended not to use them at all. Not sure if related issue has already been fixed.

I could add feature request to Dart SDK, but let's see first if I am alone with these wishes :)

[DanTup]

Personally I prefer it as it is. You can't tell from looking at the source code which packages are local and which are from pub so the ordering would still need some external data (and that means you can't tell - by looking at the code - whether the sorting is correct).

"From pub" is also a bit ambiguous. I work on some projects where packages are on pub, but in the monorepo they live in, they are referenced by other packages. This means they are "pub packages", but while you're developing them, they're being in your local workspace (eg. using dependency_overrides) and therefore "my local packages" rather than "third party packages").

In that case, either you end up with "my local packages" being treated as "third party packages", or you end up with sorting that might differ depending on what's in .packages (or pubspec.yaml) at the time you sort.

I think the sort should be consistent and deterministic without any factors outside of that file itself. You should be able to look at a file and know whether it's sorted or not, and/or sort it manually into the same order that the automatic sort would use (without knowledge of where specific packages are coming from).

[kinex]

Would this work: "third party packages (pub packages)" = All imports - Dart imports - Flutter imports - Local imports. Not sure if you can detect Flutter imports reliably (is finding "package:flutter/" reliable to flag it as a Flutter package). And "local packages"=those listed in the VS code workspace.

To find out if I am really alone with my "special ordering requirements", I found a couple of interesting links:

1. There seems to be a lint "directives_ordering" which I didn't know about, details here. Interestingly it also mentions this:
   PREFER placing “third-party” “package:” imports before other imports.
   Sounds exactly what I want too. But it seems that this lint is not working currently, see https://github.com/dart-lang/linter/issues/1844. After they fix that, does it mean that current "Sort imports" will trigger that lint error or will it be fixed too?

2. Then I found also this package https://pub.dev/packages/import_sorter, which seems to order imports as I described above (not sure about items 4 and 5). Otherwise looks great but I don't like the requirement of running an external tool to do this. It should be as automatic as _dartfmt_ on save to be really useful.

But yeah this is clearly a matter of taste. It is possible that alphabetical ordering is a preferred or at least "good enough" option for most developers. But as you noticed there ARE developers who prefer different logic for ordering imports.

[bsutton]

So I was thinking about this issue whilst in the shower :)

The ideal sort is essentially a subjective issue.

As such we need to deal with the fact that different devs will want different sort orders.
As such to keep everyone happy dart-code would need to expose a sort configuration option.
The problem with this approach is that there is already a sort configuration option in the lints.

directives_ordering - Sort directive sections alphabetically.

I would argue that the ordering should be configured in one place (the lints).

As such if a new ordering is wanted then first a new lint should be added and then dart-code should use the lint to determine the appropriate sort order.

[DanTup]

Interestingly it also mentions this:
PREFER placing “third-party” “package:” imports before other imports.

I think by "third party" here it means "packages:" imports that are not the current package rather than distinguishing between package:flutter and other pub packages. I'm not certain though.

After they fix that, does it mean that current "Sort imports" will trigger that lint error or will it be fixed too?

If the lint is changed and the sort violates the lint, I would expect it would also be fixed (I do think it would need its own fix though, as the lint and the sorting functionality are separate).

I don't like the requirement of running an external tool to do this. It should be as automatic as dartfmt on save to be really useful.

Unfortunately I don't know of a good way to do this currently. The current sorting is done by the analysis server so you'd need to not use that, and instead have a VS Code task to do it (though you can't run them on-save unless you make them processes that watch - see https://github.com/Microsoft/vscode/issues/2159).

As such if a new ordering is wanted then first a new lint should be added and then dart-code should use the lint to determine the appropriate sort order.

Yeah, that sounds like the best way to do me (though it would be the analysis server rather than Dart-Code). Whether it's worth the effort to implement may depend on the demand for alternative sorting though. cc @pq!

[pq]

I'm not sure how much general interest there is in support for multiple sort orders but should note that the guidance for 3rd party packages is being removed: dart-lang/site-www#2402 (w/ https://github.com/dart-lang/linter/pull/2098 corresponding). I haven't fully grokked your motivation @bsutton, but will that change make things better or worse in your opinion?

[bsutton]

I'm not fussed about the sort order as long as it matches the lint I have
enabled I will be happy.

On Mon, 8 Jun 2020, 11:54 pm Phil Quitslund, [e-mail]
wrote:

I'm not sure how much general interest there is in support for multiple
sort orders but should note that the guidance for 3rd party packages is
being removed: dart-lang/site-www#2402
https://github.com/dart-lang/site-www/issues/2402 (w/
dart-lang/linter#2098 https://github.com/dart-lang/linter/pull/2098
corresponding). I haven't fully grokked your motivation @bsutton
https://github.com/bsutton, but will that change make things better or
worse in your opinion?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Dart-Code/Dart-Code/issues/2489#issuecomment-640617646,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAG32OGGVRBSERPZBSWATN3RVTUPXANCNFSM4NIGDEQA
.

[Zujaj]

Ok even if we forget that "sorting by author" (which can be read also "I want to see all Firebase imports listed in one group"), this would be better compared to current sorting:

1. dart imports
2. flutter imports
3. plugin imports
4. imports from my own (local) packages grouped by package
5. imports from this package

The two most important things I want to see from the import list are these:

1. Which pub.dev plugins are used here?
2. Which local (my own) packages are referenced (outside current package)? Sometimes looking at this list points you out an architecture issue in your app.

Grouping Flutter imports and plugin imports together makes as much sense as grouping Dart imports together which is already done. Basically same for my own plugins.

Currently the list is a mess of my own plugins, Flutter plugins and 3rd party plugins. I don't know how that is useful.

What comes to relative imports, at least earlier it was recommended not to use them at all. Not sure if related issue has already been fixed.

I could add feature request to Dart SDK, but let's see first if I am alone with these wishes :)

https://github.com/fluttercommunity/import_sorter does what you need.