Sort import completions by distance from current module

[dhoulb]

The auto-import feature is amazing. Something I come across daily though is the import I want is nearly always the second or third choice.

In the screenshots below VS Code suggests to import db from ../../admin/helpers/db before ../helpers/db

I would propose that the ordering is sorted by distance from the current file. The following ESLint rule (that I use in most of my projects) does this correctly and presumably has code that can be reused: eslint-plugin-import/order (well, except we want the inverse of this — shortest distance first).

[dhoulb]

Here is an additional screenshot showing the problem suggestions too:

[andrewbranch]

So, we already do this sorting between different paths for the same symbol. This example must be three distinct dbs that just happen to share the same name, and it looks like they probably just come in the program order. The design question that remains here is what the sorting should be in a combination of these two scenarios:

Import 'db' from module "../foo" ----------------
Import 'db' from module "../foo/helpers"         | -- (aliases for same symbol)
Import 'db' from module "../foo/helpers/index" --
Import 'db' from module "../bar" ----------------
Import 'db' from module "../bar/helpers"         | -- (aliases for same symbol)
Import 'db' from module "../bar/helpers/index" --

I would think we still want to keep aliases for the same symbol grouped together. So then, sort the groups by the closeness of their closest option?

[dhoulb]

This example must be three distinct dbs that just happen to share the same name

That's correct, they're all different symbols with the same name. For context the project is a monorepo that contains multiple different apps (admin website, production app, backend serverless functions). Each has its own database code but they all have similar file layout. When I'm working on a file in the admin website I would never want the other db values.

I use the ESLint import/no-restricted-paths rule to catch when I incorrectly import across an invalid boundary, but it'd be lovely if the auto import worked too.

Regarding your design question: I think the distance sorting is the most likely requirement in nearly every case. The fact the developer has gone to the trouble of re-exporting higher up also implies they don't want highly specific imports. So I think ../foo and ../bar should be the top two suggestions, then ../foo/helpers/ and ../bar/helpers as they're further away and deeper (you're also intruding on the internal structure of the foo directory), and the two index options last (these are way too specific and unlikely to ever be wanted).

[andrewbranch]

This, like #31658 and #42005, is blocked on us not resolving full module specifiers for auto-imports until a user focuses a completion item. We can’t sort by paths because we don’t know what the paths will be when we render the list. In the simplest cases, it’s a simple relative path from the importing file to the imported one, but that can change if any of the following get involved:

• node_modules
• files named index
• symlinks
• paths
• project reference redirects

We could make a rough guess without considering these things, since as far as I can tell, the current order is basically arbitrary (based on program order). I don’t have a strong opinion on whether or not that’s worth it. My hunch is that guessing would produce correct/desirable results far more often than not, but that same-named distinctly-declared exports are rare enough that almost nobody would notice.

The same constraint doesn’t apply to codefixes—we have the full module specifier of every suggestion at the same time, so we can sort those by whatever we want.

[dhoulb]

@andrewbranch Thanks for the investigation! You're right even sorting the relative paths seems like it would solve my specific use case.

I agree it's a niche request — probably mainly useful to people who have projects with folders/structures that follow a single repetitive template, (i.e. exporting a main() from different scripts or sub modules).

[andrewbranch]

Because I find #31658 and #42005 super compelling, I plan to investigate whether we can resolve module specifiers up front in the future with the help of some additional perf investments. Because of that, I think I don’t want to implement a best-guess sorting for completions before that. But I’ll look into sorting the codefixes today.

[heroboy]

Here is my suggestion of the sort criteria

1. Current and sub paths sorted by depth from current path.
2. Rest ones sorted by depth from the root.
3. node_modules

Here is my explain:
Why node_modules is last?
Because normally I shouldn't define symbol conflit with that in node_modules, but I do, I intend to override it.

Why the order of 1 and 2?
Because a file works more closly with sub folder files. Symbols from sub folders are just like internal/private symbol. Every files/modules has their internal symbol. So show current file's internal symbol in priority.
And some base and utility symbols are not define very far from root, so show them in second.

[bpasero]

I second this and often end up getting frustrated in VSCode when imports are suggested like so:

To give more context: here I edit core VSCode code but get suggestions that are a) from a d.ts file that is not even close to the one I am in (vscode) or b) is more distant in general.

I think the rules should be to prefer imports from modules by distance but also to prefer non d.ts / node_modules imports if possible even if the distance ends up to be greater.

[andrewbranch]

This is now more or less possible since #44713 was merged, but takes quite a bit more work on top of that to implement. I’ll plan on taking a look for 4.5.