Auto-import in TypeScript suggests one outlandish choice, doesn't list reasonable ones

• 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 into node_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 the foo-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.’

[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!

[aminpaks]

@RyanCavanaugh FYI https://github.com/microsoft/vscode/issues/123683