-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Auto-import in TypeScript suggests one outlandish choice, doesn't list reasonable ones #43352
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Do you have a repo we can look at that reproduces this behavior? There's a bug in VS Code where it's showing the file path to the import (in the completion list info) when it shouldn't; frequently you will see a more-expected import path actually get generated when you invoke the completion. |
I should be able to prepare a repro. I'll post it here when I get a chance. Thanks :) |
@RyanCavanaugh any monorepo should do it. I'm facing the same issue. Having multiple Also something that I noticed is when I use auto-import it adds the same import multiple times due to having multiple instances of types I guess. Should I open another issue for that @RyanCavanaugh? |
"any monorepo" - there are about a thousand ways to configure a monorepo; this isn't an actionable description. A pretty large share of people use monorepos in some configuration or another and we'd be hearing from them already if this affected all of them. If you have a way to repro the multiple-import thing, yes, another bug on that too please. Thanks! |
A bazillion things have changed with auto-imports since this was opened. New issues with repros are welcome. |
Does this issue occur when all extensions are disabled?: Yes
I have a monorepo with a directory structure like so:
Now, in a sane world, the sort of tough problem faced by VS Code would be how to prioritize the different reasonable ways to import
MyClass
. Suppose a package (not shown) depended on both@myscope/foo
and@myscope/bar
, then there would be three possible ways to import it:I would be coming here asking, for example, how to de-prioritize the second one, because I'm using
index.ts
files with barrel exports.However, that is not the world we live in, because when I am in
currentFile.ts
(above), and I typeMyClass
, I might be offered one choice like:...with no other choices, when the correct and only reasonable place to auto-import from is (simply)
'@myscope/foo'
.This is just the most bizarre thing.
..
and descending intonode_modules
ever be given priority over a simple one?@myscope/foo
and the other referring to@myscope/bar
inside thefoo-demo
package?Before VS Code, I used Emacs, for over a decade, and the auto-import features I encountered there were similarly terrible. I've never had a good auto-import experience, at least in JS/TS. But, VS Code's feature does save me some typing, even if I have to constantly correct it, and I have hope it could one day serve me well.
Can extensions improve this experience? I have looked through the extension API a bit, but I can't find anything about influencing auto-import suggestions, even though there are apparently extensions that do this, including a popular one called Auto Import (which doesn't explain how it differs from or interacts with VS Code's built-in feature that does the same thing).
I would like to know what auto-import is expected to be able to do, or take into account, and what it simply doesn't. I feel like there is some design limitation here, like maybe the different ways of importing MyClass are considered "the same" because they ultimately come from the same original declaration? That doesn't explain why the single path chosen among many is such a bad one, though.
If I were sitting down to write an auto-import feature from scratch that needed to come up with good suggestions for how to import a symbol, I would take factors into account like:
The first one seems like a no-brainer. The second one might require architectural changes or something, but an auto-import feature that only looked at existing import statements as source material might actually be more useful and accurate a lot of the time than what the current system is doing.
When this problem isn't occurring, I actually do encounter the "in a sane world" problem mentioned above, where VS Code will not see and choose
@myscope/foo
over@myscope/foo/MyClass
even though the former is shorter, even with 'Import Module Specifier' set to 'shortest.'The text was updated successfully, but these errors were encountered: