Auto-import priority rules

[theoephraim]

trafficstars

Suggestion

It seems there are many folks struggling with the priority/ordering of VSCode's auto-import (intellisense) suggestions. There are a few different cases, but they seem to be all somewhat related to the general theme of how these suggestions are prioritized.

• My specific case is that when coding in Vue, the import of watch from fs is always prioritized over vue (/cc @cabal95)
• Others have issues with code from external modules being prioritized over code defined within their repo
• Others have issues related to preferring aliases defined in their tsconfig
• Many edge cases around specific paths suggested when dealing with monorepos...

It would be fantastic if VSCode provided a way to override the priority but it seems that TypeScript's language server suggestions could use some tweaking regardless.

⭐ Suggestion

Seems like a fairly reasonable priority would be:

• code found within the repo/module (preferring aliased paths if they exist, probably preferring "closer" imports over further away in the tree?)
• code found in other repos/modules defined locally within a monorepo (again preferring aliases)
• code found in explicit dependencies found in package.json
• code found in node internals (ex: fs, path)

---

🔍 Search Terms

import priority prioritize prioritise auto-import vscode intellisense

🔗 Related Issues

open

• https://github.com/microsoft/TypeScript/issues/31710
• https://github.com/microsoft/TypeScript/issues/43352

closed

• https://github.com/microsoft/TypeScript/issues/43849
• https://github.com/microsoft/vscode/issues/29613
• https://github.com/microsoft/TypeScript/issues/15024

[RyanCavanaugh]

None of the things you've listed are first-class concepts in TS -- basically, when we're running, it's all just files and/or ambient module declarations. Formal definitions of what it means to "be defined locally in a monorepo" or "be a node internal" would be needed

[theoephraim]

@RyanCavanaugh - thanks for replying!

Do you think there would be a willingness to add these concepts and get something implemented?

It seems this is the main file involved?

I'm thinking some of the edge cases around monorepos might get pretty nasty, but I would think sorting the explicit imports before node built-in modules may be straightforward.

[no-stack-dub-sack]

Adding another similar issue from VS Code repo that was also closed: https://github.com/Microsoft/vscode/issues/42104. It seems like on of the issues tracked in this ticket was resolved, but the main issue of import priority was not.

[jpike88]

Was going to open an issue about this... thankfully I found this one.

I would add that the way that autosuggest is matching/suggesting imports vs quick fix seems to be inconsistent.

e.g. I want to add the import line automatically: import { Assessment } from '@shared/models/Assessment';

@shared is an alias to an in-house shared types project in our monorepo.

Two types of problems seem to be apparent:

• Quick fix prefers a library imported via node_modules, which is almost always non-preferred

• Suggestion dropdown doesn't even offer it as an option, even when scrolling all the way down (whether I use 'assessment' or 'Assessment' doesn't change the results)

Tightening this all up will offer a huge productivity boost.

[rgembalik]

This is definitely annoying to our team as well - we have a lot of generic React components like <Input />, <Button />, etc. And each time the auto-import suggests alternatives found in external dependencies first, even though local code seems to be a fairly reasonable thing to prefer. Ideally, this would be something you can set in settings (e.g. "javascript.preferences.autoImportPriority": ["local", "alias", "./src/somemodule.js", "some_node_module"]). It seems like a minor problem but is often one of the most annoying things to deal with as these things tend to go unnoticed unless the component API is not the same, or someone notices that during code review.

[cheapsteak]

would be great if this could be further customizable to allow solving for collisions across external packages as well

a few anecdotal examples from our app

1. useQuery is exported by both @chakra-ui/react (for media queries) and @apollo/client (to make graphql requests), for our app we never use useQuery from chakra and always want the one from @apollo/client, but for some reason the @chakra-ui/react always shows up first
2. gql is exported by both @apollo/client and graphql-request. 99% of the time we want the one from apollo client

[MatthieuVegreville]

would really be great for us as well, we have many conflicting names of types which are imported first from the node_modules libraries rather than from our code (e.g. User, BaseEntity, etc)

[jguddas]

What about sorting suggestions by popularity?

When you already imported useQuery a bunch of times from react-query in your current project, it probably makes sense to suggest that over a useQuery exported from a module that you have never used.

There can also be other heuristics, but this feels like a good start.

[jpike88]

I thinks sane defaults would be in order:

• internal project files
• aliases in tsconfig
• node_modules

Beyond that being able to specify overrides would make sense too though.

[starball5]

Related on Stack Overflow: VS Code TypeScript auto import suggestion priority

[robiot]

Second this, Suggesting to import ex. ../../components instead of a @/components alias can get annoying.

[NonerDude]

Have a similar experience with angular, For EventEmitter the first suggestion is from the "stream" library, but the preferred option is @angular/core, this takes a few seconds each time to figure out that the wrong thing is imported.

[michael-gillett]

@robiot If you have the alias configured in your tsconfig.json, there is already a setting that should do what you want.

typescript.preferences.importModuleSpecifier: "non-relative"

Prefers a non-relative import based on the baseUrl or paths configured in your jsconfig. json / tsconfig. json.

Snippet from tsconfig.json:

{
  "compilerOptions": {
     ...
    "paths": {
      "@/*": ["./src/*"]
    }
}

Import suggestion:

[zrosenbauer]

@robiot If you have the alias configured in your tsconfig.json, there is already a setting that should do what you want.

typescript.preferences.importModuleSpecifier: "non-relative"

Prefers a non-relative import based on the baseUrl or paths configured in your jsconfig. json / tsconfig. json.

### Snippet from tsconfig.json: ```json { "compilerOptions": { ... "paths": { "@/*": ["./src/*"] } } ```

Import suggestion:

Thats a good tip, but in my case I have a design system built on top of MUI and it keeps preferring @mui vs our design system (in a monorepo using turbo)... I actually sort of hacked it with snippets by creating a couple that start with "import" i.e. "import-design-system"

[houkanshan]

You can change the auto-complete suggestions and code fix (quick fix) with a TypeScript Plugin. A TypeScript Plugin has to be a package (cannot be a local file), so I made one: https://github.com/tidalhq/ts-plugin-sort-import-suggestions

If you are interested, the sorting happens here and here

[timreach]

What about sorting suggestions by popularity?

When you already imported useQuery a bunch of times from react-query in your current project, it probably makes sense to suggest that over a useQuery exported from a module that you have never used.

There can also be other heuristics, but this feels like a good start.

I feel I could forgive having to click an obtuse option once or twice but some general user popularity score would be really nice. This should be the goal IMO. Then this should also feed into the selection process for "Add All Missing Imports".

Alternatively, maybe something we can just put in .vscode/settings.json where you can just add a suggestion blacklist.

[patroza]

I think also closest relative should be first, and prefer down the tree before up the tree. trying to import a B while in ./A/x.ts

should prefer this order: ./b.ts ./b/b.ts ./b/b/b.ts ../b.ts ../B/b.ts ../B/b/b.ts some_ts_path/* @some_npm_package/*

[odama626]

this has been driving me insane. everytimes vscode autoimports a component it crashes my dev server because it is always import the node module and not my local aliased module. is there not a workaround for this?

[theodorusclarence]

You can change the auto-complete suggestions and code fix (quick fix) with a TypeScript Plugin. A TypeScript Plugin has to be a package (cannot be a local file), so I made one: https://github.com/tidalhq/ts-plugin-sort-import-suggestions

If you are interested, the sorting happens here and here

Thanks, it works great! I just wrote a step-by-step guide so it’s easier if someone needs to implement this. Hopefully it helps.

https://theodorusclarence.com/shorts/vscode/auto-import-sort

[itzaks]

You can change the auto-complete suggestions and code fix (quick fix) with a TypeScript Plugin. A TypeScript Plugin has to be a package (cannot be a local file), so I made one: https://github.com/tidalhq/ts-plugin-sort-import-suggestions

If you are interested, the sorting happens here and here

This is great, and works with the in-file suggestions. But for auto completion on saves it doesn't work for some reason?

  "editor.codeActionsOnSave": {
    "source.addMissingImports": "always",
  }

I guess this uses the VSCode typescript and not from the workspace.

[HirokiTakekuma]

We really need this feature for monorepo projects...

[mchlkucera]

Bumping this one, would be a huge productivity booster for our team

[akodkod]

+1 for this issue

[dallenbaldwin]

I'd also like to +1 this issue.

I would definitely like to be able to trust my add missing imports context menu option again. I'm currently working on a pretty intense merge right now. In the upstream we've wrapped a function from an npm package with our own function of the same name that customizes the behavior, sets sane defaults, etc. for our needs. Now I have to manually import our wrapper function before I can trust add missing imports

Unfortunately, a lot of this is going to bleed into IDE behaviors, but maybe a temporary work around would be to auto-import everything it can find and let us remove the incorrect duplicates...

[adrian-gierakowski]

Another issue I always face is auto import from src/ instead of dist/ in a monorepo where stuff is import d directly from files instead of the index