Auto-import prefers parent index.ts which leads to circular reference

[gordonmleigh]

Bug Report

This appears to be recently changed behaviour. I have a package with an index.ts at the root:

1. I write a file a/Foo.ts which contains export const Foo = 'Foo'
2. I write a root index.ts which contains export * from './a/Foo'
3. I write a file b/Bar.ts and attempt to auto-import Foo
4. The import is written as import { Foo } from '..'.

I think that importing from an index directly above the file like this is highly likely to lead to a circular reference.

🔎 Search Terms

auto-import auto-import relative

🕗 Version & Regression Information

• This changed between versions 4.3.5 and 4.4.2

⏯ Playground Link

See simple repro.

💻 Code

// index.ts
export * from './a/Foo';

// a/Foo.ts
export const Foo = 'Foo';

// b/Bar.ts
import { Foo } from '..'; // this is the resulting import

const Bar = Foo; // try to auto-import this

🙁 Actual behavior

Imports from parent index.ts. This file is highly likely to also import the importing file, causing a circular reference.

🙂 Expected behavior

Import from './a/Foo' instead. Or, put another way, prefer not to import from a path which has only one or more .. in it.

[JonWallsten]

Since my branch was auto closed I'll move some information to this one.

It broke in this release: It broke in typescript@4.4.0-dev.20210626

Most likely in this commit:
Resolve module specifiers for auto imports in completion list 328e888

My thoughts:
I appreciate that it's hard to figure out what to do, because it's impossible to know the users intentions. One solution could be to either have an option for or always also show the "source file path" when it's reexported. I think it was like that before:

It would at least give the user a choice, but I agree it's not optimal since it creates a mess in the suggestion lists and I guess it was why this was "fixed"?

Another solution could be to have an option for or always ignoring re-exports from the entry point or all index.ts (or all re-exports and always resolve the source file).
That entry point at least is most likely for consumers of the package, and not to be used internally.
I'm conflicted about other nested index.ts files in the project. It could be a case where you have a utils/index.ts to expose utils for your own needs, but auto imports removes the need for that. I guess it also messes with tree shaking.
But if it's about all or nothing, I would be glad to have the option to always resolve the source file when importing files locally in a package.

[rezonant]

Can exhibit as well with a '.' import, seems to just depend on how far up the symbol is exported.

My example from #46817 was:

Given a folder with:

// index.ts
export * from './a';

// a.ts
export class A {}

// b.ts
export class B extends A {}

...an attempt to use auto-import to resolve the reference to A in b.ts will insert:

import { A } from '.';

...instead of the preferred (and the one provided by previous versions of VS Code):

import { A } from './a';

[rezonant]

Duplicate of #45953. We’ll probably drop paths that resolve to nothing but dots and slashes as that often creates an import cycle between a barrel re-export and the file that’s importing it (which may not be a problem at runtime, but can be if the modules have side effects, and I’ve just never seen anyone use import paths like that on purpose).
#47040 (comment)

It is a huge relief to hear that there is an intent to fix here, auto-importing is effectively useless in VS Code right now due to this issue :-( Have been working around it but if I don't notice it happens it inevitably causes problems at runtime, usually due to decorator references or runtime type metadata.

[inca]

Sorry to pitch in without any additional info (I think the problem description is spot on), I would only like to note on the severity of this: right now VS Code + TypeScript >= 4.4.0 is effectively unusable if the modules are structured using re-exports. In the codebases that adopt this pattern at scale, all auto-imports must be essentially re-written manually, which is a huge bummer. The only sensible alternative at the moment is downgrading to TypeScript < 4.4.0 which can also tricky because the codebase may already have adopted the 4.4's breaking changes.

Hoping this will get resolved soon 🤞