Repository navigation
Sort import completions by distance from current module #41083
Description
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).
Activity
dhoulb commentedon Oct 13, 2020
Here is an additional screenshot showing the problem suggestions too:
[-]Auto-import sorting potential imports by distance[/-][+]Sort import completions by distance from current module[/+]andrewbranch commentedon Oct 14, 2020
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: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 commentedon Oct 28, 2020
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
dbvalues.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
../fooand../barshould be the top two suggestions, then../foo/helpers/and../bar/helpersas they're further away and deeper (you're also intruding on the internal structure of thefoodirectory), and the twoindexoptions last (these are way too specific and unlikely to ever be wanted).13 remaining items
andrewbranch commentedon Jul 6, 2021
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.