Skip to content

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

Closed
dgreensp opened this issue Mar 23, 2021 · 6 comments
Labels
Needs More Info The issue still hasn't been fully clarified

Comments

@dgreensp
Copy link

  • 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.'

@mjbvz mjbvz transferred this issue from microsoft/vscode Mar 23, 2021
@mjbvz mjbvz removed their assignment Mar 23, 2021
@RyanCavanaugh
Copy link
Member

RyanCavanaugh commented Mar 23, 2021

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.

@RyanCavanaugh RyanCavanaugh added the Needs More Info The issue still hasn't been fully clarified label Mar 23, 2021
@dgreensp
Copy link
Author

I should be able to prepare a repro. I'll post it here when I get a chance. Thanks :)

@aminpaks
Copy link
Contributor

aminpaks commented May 7, 2021

@RyanCavanaugh any monorepo should do it. I'm facing the same issue. Having multiple node_modules in the parent folders seems to cause the issue.

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?

@RyanCavanaugh
Copy link
Member

"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
Copy link
Contributor

@andrewbranch
Copy link
Member

A bazillion things have changed with auto-imports since this was opened. New issues with repros are welcome.

@andrewbranch andrewbranch closed this as not planned Won't fix, can't repro, duplicate, stale Jun 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs More Info The issue still hasn't been fully clarified
Projects
None yet
Development

No branches or pull requests

5 participants