auto-import using yarn link protocol, is importing the path, rather than the name

In my package.json, I have the following yarn link protocols set up in dependencies:

"modules": "link:./src/modules",
"mocks": "link:./__mocks__",

When I auto-import a dependency from either of these files, the import statement looks like this:

import { foo } from 'src/modules/foo'
import { bar } from '__mocks__/bar

And while this does compile and work fine, I would expect the imports to look like this:

import { foo } from 'modules/foo'
import { bar } from 'mocks/bar'

If I manually adjust the imports to my preferred format, it also works fine. But why would vscode be pulling the import path from the right side of the declaration, rather than the left side? Am I incorrect in my assumption that it should be using the ‘name’, rather than the path for the imports? All other dependencies reference the package name when being imported.

Verified that this behaves the same with all extensions disabled.

VS Code version: Code 1.62.3 (Universal) (ccbaa2d27e38e5afa3e5c21c1c7bef4657064247, 2021-11-17T07:59:13.865Z) OS version: Darwin arm64 21.1.0 Restricted Mode: No

System Info

Item	Value
CPUs	Apple M1 Max (10 x 24)
GPU Status	2d_canvas: enabled gpu_compositing: enabled metal: disabled_off multiple_raster_threads: enabled_on oop_rasterization: enabled opengl: enabled_on rasterization: enabled skia_renderer: disabled_off_ok video_decode: enabled webgl: enabled webgl2: enabled
Load (avg)	3, 3, 4
Memory (System)	32.00GB (1.13GB free)
Process Argv	–crash-reporter-id eee85e01-b198-4016-a620-0f026921ed6f
Screen Reader	no
VM	0%

Extensions (26)

Extension	Author (truncated)	Version
multi-cursor-case-preserve	Car	1.0.5
path-intellisense	chr	2.6.0
vscode-svgviewer	css	2.0.0
vscode-eslint	dba	2.2.2
githistory	don	0.6.19
prettier-vscode	esb	9.0.0
beautify	Hoo	1.5.0
vscode-peacock	joh	4.0.0
chat	kar	0.35.0
expand-region	let	0.1.4
HTMLHint	mka	0.10.0
vscode-duplicate	mrm	1.2.1
vsliveshare	ms-	1.0.5090
vsliveshare-audio	ms-	0.1.91
vsliveshare-pack	ms-	0.4.0
vetur	oct	0.35.0
vscode-subword-navigation	ow	1.2.0
partial-diff	ryu	1.4.3
vscode-multiclip	sle	0.1.5
language-stylus	sys	1.14.1
vscode-counter	uct	2.3.0
alphabetical-sorter	ue	2.0.1
vscode-icons	vsc	11.7.0
gitblame	wad	8.1.0
wallaby-vscode	Wal	1.0.319
intelligence-change-case	zhe	1.1.0

(1 theme extensions excluded)

A/B Experiments

vsliv368cf:30146710
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vstes627:30244334
pythontb:30283811
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscoreces:30384385
pythondataviewer:30285071
vscod805:30301674
pythonvspyt200:30340761
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
pythonrunftest32:30373476
pythonf5test824:30373475
javagetstartedt:30391933
pythonvspyt187:30373474
vsaa593:30376534
vscexrecpromptt2:30404948
vscop804:30404766
vs360:30404995
vsrem710:30405998

[thepuzzlemaster]

Oh, interesting! So this definitely was not happening for me. Every time I’d auto-import, it would use the incorrect version, based on the root path, regardless if that import exists in other files, or other similar imports exist in the current file. But your comment about tsconfig/jsconfig gave me an idea. I removed the baseUrl entry in my tsconfig.json, and now auto-importing IS using the symlink path! This is a huge improvement!

[thepuzzlemaster]

FWIW, this will be much less painful for me now, knowing the behavior without a baseUrl entry gets me 95% of the way there. I can’t think of any reason I would need the baseUrl, so I would be okay with this not meeting the bar of things to work on. I’m sure your backlog is full of great ideas that would have a larger impact than this. I’d certainly be open to hearing other peoples’ thoughts if anyone feels differently. But I wouldn’t mind closing the issue if no one else chimes in.