Auto-import priority rules

[theoephraim]

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

• Prioritise import suggestions from tsconfig alias over external dependencies #31710
• Auto-import in TypeScript suggests one outlandish choice, doesn't list reasonable ones #43352

closed

• TypeScript Should Prioritize Aliased Imports #43849
• Sorting of intellisense suggestions not optimal in this case vscode#29613
• favor local types and values in autocomplete popup over ambients declaration #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: microsoft/vscode#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 , , 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