-
Notifications
You must be signed in to change notification settings - Fork 13k
Description
- VS Code Version: 1.54.3
- OS Version: macOS 10.14.6
Does this issue occur when all extensions are disabled?: Yes
I have a monorepo with a directory structure like so:
@myscope/
foo/
package.json
node_modules/
...
MyClass.ts
index.ts <- exports MyClass
bar/
package.json <- depends on @myscope/foo
node_modules/
...
index.ts <- re-exports MyClass
bar-demo/
package.json <- depends on @myscope/bar
node_modules/
...
baz/
package.json <- depends on @myscope/foo
node_modules/
...
currentFile.ts
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:
import { MyClass } from "@myscope/foo";
import { MyClass } from "@myscope/foo/MyClass";
import { MyClass } from "@myscope/bar";
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 type MyClass
, I might be offered one choice like:
MyClass (@myscope/foo/MyClass) > Auto import from '../foo-demo/node_modules/@myscope/bar'
...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.
- Why would a convoluted path involving
..
and descending intonode_modules
ever be given priority over a simple one? - Why isn't the "correct" module path (or any others) at least listed alongside the weird one as an option?
- Why does the gray text next to MyClass (rendered in parentheses in the snippet above) disagree with the part that says "Auto import from...", with one referring to
@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:
- Is the symbol exported by a module that is already being imported from in this file?
- How is this symbol usually imported in this workspace?
- What is available in the nearest node_modules?
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.'