typescript-language-server local node_package checks

[georgeharker]

So there's something in the settings for typescript-language-server.vim that causes it to block if there isn't a node_modules folder above in the directory hierarchy of the buffer being edited.

Took me a long time to figure out this was why a server installed with LspInstallServer wouldn't start, but a locally npm installed one would (for ages I thought it was failing to see the one lap-settings installed and instead finding the manually npm installed one. Turns out it just needed any old node_modules folder somewhere above the file being edited.

I am guessing this is for security? Would it be possible to document this though as it is pretty opaque behavior - and in my case I was just editing js for a local project, rather than a full blown node app.

Anyway, this is still a great leg-up on getting things working and I've been using this for years on python stuff, just got a bit stuck today and think it could avoid others doing the same to document the behavior.

[mattn]

Will detecting package.json file help you?

[georgeharker]

For it to work I have to have a node_modules folder somewhere in the hierarchy above the edited file. Installing with npm from the command line in my home dir effectively put that in ~/node_modules which meant the blocklist didn't take effect as it crawled up the dirs from my project to ~/. Confusing as I thought it was because I'd installed the lang server there - but it could have been anything. When I removed that install, it meant the blocklist in the default settings for typescript-language-server applies and blocks any js file (or typescript). To fix I had to have a blank npm_modules directory next to my js files. I assume there's a security thing here. But I don't know for sure. Maybe the intention was for use with node which would make it make sense to look for a node modules folder. This is the static portion of a python / flask project so no node involved. Just took a chunk of echo statements and understanding the vim script in the plugin to figure it out - a docs note is probably all that's really needed (if security means running without such a dir somewhere is a bad idea, otherwise removing the blocklist would work).

[georgeharker]

Ah. I see - rather than node_modules, yes. I think that would be totally workable!

[Daghall]

I made the same debugging journey, and found a quick and dirty solution:

mkdir ~/node_modules

I have some web-only projects that do not use any node modules, so looking for a package.json will not do the trick for me. I am fine with having the empty ~/node_modules, though. I am just glad I finally found the problem and solution. 😄

What is the rationale for blocking files/folders that are not descendants of a node_modules-bearing directory?

Thank you for this awesome vim-plugin! 🙏

[sabakuro]

I also made the same debugging journey today until finally stumbling across this issue.🤣

May I ask where I can find the blocklist/how do remove it? Adding an empty node_modules directory worked for me as well, but it feels like a hacky solution for a barebones project (in my case, a simple Chrome extension).

Update I was able to find the blocklist here: https://github.com/mattn/vim-lsp-settings/blob/16f65b3d5ed4be5aae439ffddd4801bab204fab7/settings/typescript-language-server.vim#L19

Deleting the line made it work as expected so this seems like another possible solution, but I'm curious to know the reason behind this blocklist as well. Thanks!

[klarkc]

+1, In my project I'm not using node_modules cause I'm only using client-side javascript, without the npm tooling. Does typescript-language-server crashes without node_modules?

[Daghall]

+1, In my project I'm not using node_modules cause I'm only using client-side javascript, without the npm tooling. Does typescript-language-server crashes without node_modules?

It doesn't crash, but it doesn't start either.

If you add a node_modules folder (it may be empty) to your user's home directory, it will mitigate the problem for all future projects. Quick 'n' dirty, but it works.