Update "Import library" correction to account for linter rules

[Mike278]

Dart SDK version: 3.3.0-48.0.dev (dev) (Fri Oct 20 09:02:07 2023 -0700) on "windows_x64"

Steps to reproduce:

• Create a new dart project
• Replace the contents of analysis_options.yaml with

  linter:
  rules:
  prefer_relative_imports: false
  avoid_relative_lib_imports: true # Probably redundant
  always_use_package_imports: true # Probably redundant

• Create a new file lib/foo.dart with contents const hello = 'world';
• Create a new file lib/bar.dart with contents const greeting = hello;
• Open the project in IntelliJ and enable Dart support (I haven't tested this in any other editor)
• Navigate to lib/bar.dart, place the cursor on hello, and generate suggestions with alt+enter
• Expected: Import library 'package:import_bug/foo.dart' is the first (and ideally, only) suggestion
• Actual:

This function seems to suggest the order depends on the value of prefer_relative_imports, but changing this value doesn't change the order.

Might be related to https://github.com/dart-lang/sdk/issues/32916 where support for relative imports was added?

[Mike278]

[...] (I haven't tested this in any other editor)

I should have! This works as expected in VSCode.

Interestingly if I rename foo.dart to zzz.dart the order flips, so IntelliJ is sorting it alphabetically somewhere.

[bwilkerson]

The ordering of completion suggestions produced by the analysis server is taken as "advice" from most editors / IDEs. We can't change the behavior of the editors, so there's probably nothing we can do to improve this situation.

[Mike278]

Looks like this might be the API to do it for IntelliJ?

Alternatively, what if the "Import Library" correction also took into account other preferences like avoid_relative_lib_imports or always_use_package_imports? If it could be configured such that there's only ever one correction in the list then the order doesn't matter.

[bwilkerson]

... what if the "Import Library" correction also took into account other preferences ...

That's a direction we're definitely interested in moving toward. We have started using lint enablement to control some other code generation styles (fixes, iirc), and should do so here as well.