Open theoephraim opened 1 year ago
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
@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.
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.
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.
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.
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
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 gql
is exported by both @apollo/client
and graphql-request
. 99% of the time we want the one from apollo clientwould 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)
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 thinks sane defaults would be in order:
Beyond that being able to specify overrides would make sense too though.
Related on Stack Overflow: VS Code TypeScript auto import suggestion priority
Second this, Suggesting to import ex. ../../components instead of a @/components alias can get annoying.
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.
@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.
{
"compilerOptions": {
...
"paths": {
"@/*": ["./src/*"]
}
}
@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:
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"
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
What about sorting suggestions by popularity?
When you already imported
useQuery
a bunch of times fromreact-query
in your current project, it probably makes sense to suggest that over auseQuery
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.
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.
watch
fromfs
is always prioritized overvue
(/cc @cabal95)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:
fs
,path
)🔍 Search Terms
import priority prioritize prioritise auto-import vscode intellisense
🔗 Related Issues
open
closed