Typescript Language service not finding symbolic linked (junction) npm module #25312
Comments
|
As a personal anecdote - I have 6 or 7 TypeScript based projects, all symlinked together locally, and unfortunately I cannot get static typing across them, the way I would if they were actually installed in node_modules instead of symlinked. It's a huge loss. :( |
|
Also just hit this problem... |
|
+1 |
|
This is an issue for me as well. |
|
This is causing problems for me as well with local development. |
|
This only seems to happen in large projects. I've created a small example and intellisense worked well. My other project has a similar setup and absolutely no intellisense 😕 |
|
@SteveALee Hey sorry this fell off my radar. Are you still running into this issue with typescript@2.7-insiders under the current vscode insiders? If so, let's move this issue over the the TS repo. Someone over there should know more about the expected behavior for linked modules and if there are any workarounds |
|
Same problem on TS 2.6.2, VSC 1.19.1 :( |
|
@skorunka thanks! |
|
Still same problem here on TypeScript 2.7.2 and VSC 1.21.0 |
|
Also seem to be having this problem. Typescript (+ tsdk used by VSCode) 2.8.1 |
|
Still same problem here on TypeScript 2.8.1 and VSC 1.22.1 |
|
@mjbvz I not find a problem as this. It still exists in the latest version |
|
@linmodev try restarting the typescript server inside of vscode using the command palette, that seemed to have worked for me. |
|
Here to confirm that @bogthe workaround fixed it for me.
|
|
"Restart TS server" does not help me here. I created symlink via 'npm link '.
I believe |
|
Hi @gobengo not sure what steps did you followed but this is what I did and it worked for me (I am on a Mac though): In source project: Then: And everything worked .. not sure if you did it similar |
|
@orlaqp this seems to be specific to Windows' symlinks. (Restarting the TS server has no effect for me.) |
|
@orlaqp @zbjornson Yeah. I'm using Debian on Windows Subsystem for Linux (Windows 10) |
|
To everyone here, check out --preserveSymlinks flag. I just found it, I'll see if I can make it work |
|
Why would that not be on by default though? Strange choice. Looking forward to hearing if it works. |
|
It worked! Yes, I would find it more useful to have it on by default or at least provide some kind of suggestion when there are errors with symlinks. For example "You got an error with a symlink, you should douvble check that --preserveSymlinks is set to the desired value". User (developer) experience is very important... |
|
Actually it didn't :/ It appeared to work because I had set "rootDir": "C:\Users\biels" in tsconfig.json after hours of messing with it. But it is still not behaving as expected. The --preserveSymlinks is a flag that switches between resolving the symlink (to its canocical path) vs treating it as a file that contains a reference to a directory. |
|
What about treating symlinks as if it were portals (not just shortcuts)? That you could access files using a symlinked path the same way you do with normal ones.
And then access C:\project1\symlink\src. Notice how src is still under project1 which would appear to be under the rootDir. |
|
Plus npm uses links explicitly if you have a local version of a dependency module |
|
i npm link and/or yarn link monorepos on a daily basis. i can confirm that linked typings files do not get updated realtime, onchange. i'm on OSX, so restarting the TS Server does work, but it's a hack. i assume that the solution path will be the same for all of us. just adding another data point to the mix. |
|
I just got hit by this bug too, using If you're doing local library development, here's an ugly hack that will at least allow you to keep moving until you publish on npm:
VSCode will recognize that sym link, just not the one in It's certainly not ideal, but at least it's workable. |
|
Come on please fix this. It can't be that hard... This has been around for too long already. |
|
Same for me as @cdaringe. I: In ProjectA: Both projects are open in VSCode. I have a |
|
I had a similar issue when working with yarn workspaces (as per @efokschaner) within a WSL environment. After a good bit of searching I came across issue microsoft/WSL#3611 with the following comment: More or less it seems like you can enable developer mode within windows 10 and apparently all your problems go away. Which was true in my situation at least. |
|
@DamonOehlman I tried to no avail. The symlinks work fine in the terminal and stuff, but the typescript checking in vscode always complains about not being able to find the |
|
I should've mentioned I'm on a Mac. If there's more info that could be helpful, let me know and I'll provide it. |
|
Come on guys, this is killing us, symbolic links is bread and butter for efficient development, please get this addressed. It took a while to get node, nodemon, npm/yarn and everybody else on board, vscode is the last hold out.... My experience that this does not work is on macos. |
|
I resolved this by adding {
"compilerOptions": {
"moduleResolution": "node"
}
}I'm not sure that will work universally, since the OP has both lines, but it works in two projects for me. Interested to know if it works for others. Details: With For reasons I don't understand yet, linked modules don't resolve from VSCode in "classic" mode, although non-linked commonjs modules in Make a file with //@ts-check
const foo = require("some-linked-module")and then run: vs. Possibly relevant: microsoft/TypeScript#26819 microsoft/TypeScript#18492 |
|
@zbjornson I appreciate your effort to explain how if we set up our project in a certain way then the problem is worked around, but in most real world, ie non vscode demo, projects there are many conflicting reasons on how to set up the project. Usually the IDE is the last one to be considered. After all, there is an obvious workaround to this issue: not use symbolic links. But there is some other reason, having nothing to do with VSCode that led us to use symlinks in the first place. In general, if it works from the command line it should work from the IDE. The issue here is that on both windows and unix/macos something that works on the command like does not work from inside the VScode IDE and this is what we want to see addressed. |
|
As I commented in microsoft/vscode-go#1307 (comment), I suspect that the problem is beyond |
|
Literally spent days figuring out why my mono-repo using work workspace has issues detecting imports from other packages. Still haven't found the ideal solution yet. Update: |
|
I found the key to solve this problem!:
Then typescript language service will work! I ran into this problem when I split my package with lerna, and my typescript is More infomation: https://www.typescriptlang.org/docs/handbook/declaration-files/publishing.html |
|
Hi @linkdesu , was your problem has anything to do with symbolic links, or it was only about package splitting? |
|
Just wanted to add 2c, but this is my biggest time waste per-day in VSCode. I didn't know about just restarting TSServer, but either way in a big monorepo I'm often "refreshing" VSCode ~100x a day. |
|
Just wasted about an hour on this as well. Deleted the link, copied pasted the link contents to a regular folder in node_modules, and no longer receiving errors. |
|
I had this issue, was driving me crazy. Tried everything suggested above and nothing worked. |
|
I don't see a lot of love for plain old Visual Studio 2017, but I will add my 2 cents that it is also a problem in here on typescript 3. Funny though as it is a bit of both:
That property is newly added to a library that it is coming from, so it does give a suggestion. But keeps showing an error: I still have another problem though, one library has a dependency on another library, so once I have linked all the libraries (including the dependency lib) I get All libraries are automatically updated into |
This worked for me! Using windows. |
|
Issues about project structure or resolution are upstream issues from the TypeScript project. If you are still seeing issues related to these and are using the most recent version of TypeScript in your workspace, please file a bug report upstream. Be sure to include a set of repo steps so that we can investigate |
A symbolic link (NTFS junction) to a library package in node_modules breaks code's intellisense ability to find the module, even though building from the command line works fine. This makes node dev a pain when developing a lib and consuming package and don't want to go through the publish / install loop
foo.{ "compilerOptions": { "module": "commonjs", "moduleResolution": "node", "sourceMap": true, "declaration": true, "rootDir": "src", "outDir": "lib", "target": "es2015", "lib": [ "dom", "es2016" ], "noImplicitAny": false }, "include": [ "src/**/*" ] }Create and compile another package
consumerwith a file that references the lib with animport {foo} from 'lib'Copy the lib into the consumer's node_modules - as if it had been `npm install'ed
Look at the import line in code - all intellisense is good. lib is found
Delete node_modules\lib
Either manually link by adding a junction or use
npm link ..\liblib is navigable in the code file browser (on left)Look at the import line in code - 'lib' has red squiggle and hover displays '[ts] Cannot find module 'lib'.'
I can supply all files if required, but the lib is just a single file with a single export and consuming code references it. basic stuff.
The text was updated successfully, but these errors were encountered: