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

[thepuzzlemaster]

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]

I'll also add, fwiw, if you already have an existing import using the module name, it will add to that existing import, rather than create a new one using the path.

e.g. in the example above, if I also add baz as an auto-imported dependency, it would look like:

import { bar, baz } from 'mocks/bar'

rather than:

import { bar } from 'mocks/bar'
import { baz } from '__mocks__/bar'

[mjbvz]

Please share a minimal example project that demonstrates this problem

[thepuzzlemaster]

Okay, after further investigation while creating a minimal example project, I realized that vscode actually is completely unaware of the yarn link protocols when it comes to auto-importing. What is actually happening here, is setting up a "baseUrl": "." in my tsconfig.json file, and so all import paths are based off that baseUrl, which just so happens to always align with the "path" portion of the yarn link protocol.

So I suppose, rather than a bug, this should be a feature-request for vscode to recognize the existence of a yarn link protocol, and use that for imports.

Here's the repro (note the yarn-link-protocol-defect branch).

If you auto-import myMock in any of the files under "pages", you'll see it imports based on the baseUrl set up in the tsconfig. If you remove the "baseUrl" property in tsconfig, it'll import a relative path.

If you've run yarn install, you can do import {myMock} from 'mocks/myMock'. It'd be lovely if vscode could use that by default, as it (usually) does with path aliases setup in tsconfig.json.

[JeppeKlitgaard]

I would also love to see this feature, which is sorely missed for people using Yarn 2+ and absolute imports via the link protocol.

[mjbvz]

Moving upstream to get more feedback from the TS team

Possible related: #37414

[andrewbranch]

Does any package manager besides yarn respect this protocol?

[thepuzzlemaster]

Not that I'm aware of. I believe this is a yarn-specific protocol.

[andrewbranch]

if you already have an existing import using the module name, it will add to that existing import

This should also work cross-file in the same project as long as you have a tsconfig.json/jsconfig.json. I.e., once anything in your project imports from the symlink path, do auto-imports in other files use the symlink path too?

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

[andrewbranch]

Hesitant to commit to adding yarn-specific resolution logic when the time-tested workaround of “just write it once and you’re good to go” is working, but will listen for feedback and gauge demand here in this thread.

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