Auto import suggests different paths based on if any import is exported in parent index.ts

[JonWallsten]

Issue Type: Bug

Auto import in VS Code suggests different import paths for export from the same source file if any of the exports are re-exported in for example the library's entry point. When working with our library we want to import from the source file in the library and not the entry point exposing thing for consumers. We use project-relative as Import Module Specifier since we have a monorepo using paths. But we have tried every setting without luck.
This is relatively new behavior, but I can't say exactly when it started to occur.

Repro:
https://github.com/JonWallsten/vscode-repro

1. npm i
2. Open ./lib/utils.ts in VSCode
3. Remove imports
4. Put cursor after double and use ctrl+space to show auto import suggestion (it will be "..")
5. Put cursor behind power and use ctrl+space to show auto import suggestion (it will be "./number")

We are not interested in consuming our own entry point and would like the imports to be the source file and not the entry point since it's for external consumer.

VS Code version: Code - Insiders 1.63.0-insider (b614fb5, 2021-11-09T10:02:27.095Z)
OS version: Windows_NT x64 10.0.19043
Restricted Mode: No

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-10850H CPU @ 2.70GHz (12 x 2712)
GPU Status	2d_canvas: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: enabled opengl: enabled_on rasterization: enabled skia_renderer: enabled_on video_decode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled
Load (avg)	undefined
Memory (System)	31.78GB (17.47GB free)
Process Argv	--crash-reporter-id fc1c87ea-0388-48f3-b9dd-ecad6ea37b51
Screen Reader	no
VM	0%

Extensions (9)

Extension	Author (truncated)	Version
ng-template	Ang	13.0.0
vscode-eslint	dba	2.2.2
gitlens	eam	11.6.1
vscode-npm-script	eg2	0.3.23
docthis	oou	0.8.2
vscode-versionlens	pfl	1.0.9
vscode-scss-formatter	sib	2.3.2
es6-string-html	Tob	2.11.0
vscode-icons	vsc	11.7.0

A/B Experiments

vsliv695:30137379
vsins829:30139715
vsliv368cf:30146710
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythontb:30258533
pythonptprofiler:30281269
vshan820:30294714
pythondataviewer:30285072
vscod805:30301674
pythonvspyt200:30323110
vsccppwt:30382699
bridge0708:30335490
pygetstartedt2:30353727
bridge0723:30353136
pythonrunftest32:30365365
pythonf5test824:30361779
javagetstartedc:30350118
pythonvspyt187:30365360
pydsgst2:30361790
vsaa593cf:30376535
vsc1dsc:30394499

[andrewbranch]

Duplicate of #45953

[JonWallsten]

@andrewbranch
I started to dig around a bit. This is from 4.3.5 (latest VSCode Insiders) mentioned in #45953:

It shows the absolute path in the auto import suggestion but gets the correct relative path selected.

[JonWallsten]

It broke in [email protected]

[JonWallsten]

@andrewbranch Probably this commit:
Resolve module specifiers for auto imports in completion list 328e888

[JonWallsten]

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.

[typescript-bot]

This issue has been marked as a 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.