Repository navigation
Sort import completions by distance from current module #41083
Description
Activity
- addedEffort: ModerateRequires experience with the TypeScript codebase, but feasible. Harder than "Effort: Casual".Requires experience with the TypeScript codebase, but feasible. Harder than "Effort: Casual".Help WantedYou can do thisYou can do thisSuggestionAn idea for TypeScriptAn idea for TypeScript
on Oct 14, 2020 - changed the title
[-]Auto-import sorting potential imports by distance[/-][+]Sort import completions by distance from current module[/+]on Oct 14, 2020 andrewbranch commented
on Oct 14, 2020 MemberMore actionsSo, 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?
This example must be three distinct
dbs that just happen to share the same nameThat'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).Reacted by chenjg88, ExE Boss and Eugene13 remaining items
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.
Reacted by Toni Villena, Benjamin Pasero and Duarte MonteiroReacted by Toni Villena and Dave Houlbrooke- addedExperience EnhancementNoncontroversial enhancementsNoncontroversial enhancementsand removedEffort: ModerateRequires experience with the TypeScript codebase, but feasible. Harder than "Effort: Casual".Requires experience with the TypeScript codebase, but feasible. Harder than "Effort: Casual".Needs InvestigationThis issue needs a team member to investigate its status.This issue needs a team member to investigate its status.
on Jul 6, 2021 - addedFix AvailableA PR has been opened for this issueA PR has been opened for this issue
on Nov 5, 2021

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
dbfrom../../admin/helpers/dbbefore../helpers/dbI 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).