Linked dependencies resolves to file system path

[Muritavo]

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.58.0
• OS Version: MacOS 11.4 (Big Sur)

Obs: Not related to OS, as other OSs have the same problem

Steps to Reproduce: (A reproducible cenario can be found here)

1. Use the link feature of npm to link a dependency to a local copy by using a symbolic link

yarn link SOME_DEPENDENCY

2. Now when using the intellisense feature to auto import, it resolves the dependency to the relative filesystem path instead of the node_modules require path.
   For example:

// Instead of resolving as a require path
import {something} from "dependency/something";

// It resolves to the relative path
import { something } from "../../../../some/unrelated/path/dependencyFolder/something"

[antoniohansen]

I have this issue too! Any updates?

[italofelipe]

I'm having this issue either.

[andrewbranch]

There are so many reasons why this doesn’t work, and only one of them is something we can easily fix. I think the easiest way to explain the problems is by explaining how we would generally expect this to work under today’s architecture, and then point out all the reasons why this example code doesn’t work that way. Here’s what should happen, at a high level:

1. You open the vscode_linked_dependency_bug folder in VS Code and open the Dependant/index.js file
2. We see Dependant/package.json and use it to scan node_modules for auto-imports
3. We see Dependant/node_modules/dependency_bug and add it to the auto-import list, discovering that it’s a symlink as we go
4. You ask for completions and we query the auto-import list, preferring the symlink because it gives us a nice node_modules-style module specifier

Here are all the reasons why that doesn’t work:

• (2) We don’t see/process Dependant/package.json for auto-imports, because it’s not at the project root. When you don’t have a tsconfig/jsconfig file, we assume the project root is the folder you opened in VS Code. So, the only place we look for a package.json to scan for auto-imports is vscode_linked_dependency_bug itself, which doesn’t have a package.json. You can fix this yourself by adding a Dependant/jsconfig.json file. But JS users usually don’t know to do this, and it would be nice if we could infer the monorepo structure of the folder you’ve opened and set up multiple inferred projects with their root directories set appropriately. But this would be a huge, scary change that could break a ton of stuff.
• (2) Even if we did find that package.json, it doesn’t specify dependency_bug as a dependency. This purely a user configuration error; we would never offer auto-imports for a node_module that’s not listed in your package.json.
• (3) Even if we discovered Dependant/node_modules/dependency_bug/package.json, its main field points to index.js which does not exist. The file you wanted to import was called soSomething.js, which can’t be found from its package.json file. This is probably part user error and part design limitation for us. It would be nice if we could just scan the whole directory for files to auto import, but that can get really expensive really fast. Maybe it would be reasonable to do when we discover that it’s a symlink to a local project, but this would actually be a pretty big change.
• (3) Even if the main field of the dependency package.json was set correctly, the auto-import provider currently only resolves type definition files, not JS files, even for inferred JS projects. This is the one small, easy fix for us.

So, this issue is not just a bug, it’s one bug, one or two feature requests, and one or two user config errors wrapped up in one report. I can fix the bug as part of TS 4.4, but (@DanielRosenwasser) it sounds like we need to have a larger discussion around how to be smarter about unconfigured JS projects, or at least how we can nudge the authors of those kinds of projects toward successful configurations.