mason.nvim icon indicating copy to clipboard operation
mason.nvim copied to clipboard

Some languages have incorrect startup paths

Open dxy2233 opened this issue 2 years ago • 7 comments
trafficstars

I've searched open issues for similar requests

  • [X] Yes

I've manually reviewed logs to find potential errors

  • [X] Yes

I've recently downloaded the latest plugin version of mason.nvim

  • [X] Yes

Problem description

屏幕截图 2023-05-22 103005

As shown in the image. The annotation content is the generated invocation path when downloading that language. The non-commented part is the modified path that can be correctly invoked.

The operating environment is within WSL 2 with Arch Linux, and I'm unsure if it's influenced by other configurations.

Expected behavior

Configure the correct path.

Steps to reproduce

After the default installation, it is not possible to use it. Opening the log information indicates that the path content is not found.

Affected packages

all

Neovim version (>= 0.7)

0.9

Operating system/version

wsl2, arch

Healthcheck

No problem

Screenshots or recordings

No response

dxy2233 avatar May 22 '23 02:05 dxy2233

I'm having some difficulties understanding what the issue is.

Is it correct that in the image you've provided, the visible buffer displays the contents of ~/.local/share/nvim/mason/bin/vue-language-server?

Can you also provide :checkhealth contents? What version of npm do you have installed?

williamboman avatar May 22 '23 13:05 williamboman

Some languages have incorrect invocation paths after installation, such as vue-language-server and emmet-ls.

checkhealth may be no problem.

屏幕截图 2023-05-23 150359 屏幕截图 2023-05-23 150452

dxy2233 avatar May 23 '23 07:05 dxy2233

I don't recognize the script contents of the executable (this is provided entirely by npm). Due to how it's implemented (it relies on relative paths from the executable itself) it's not compatible with the symlinking of executables that Mason does. I will need to investigate exactly what happens on WSL.

williamboman avatar May 26 '23 08:05 williamboman

The script is a shim script that npm normally outputs on Windows. The logic to output shims vs creating symlinks can be seen here: https://github.com/npm/cli/blob/latest/node_modules/bin-links/lib/link-bins.js

I think what happened is that the Windows-installed npm was called when Mason installed the packages for these language servers, which causes the shims to be output instead of symlinks. I encountered this myself, and after installing Node in WSL, thus making npm invoke an instance installed in WSL, the npm packages installed by Mason then had symlinks in .bin and everything works correctly.

Trildar avatar Sep 12 '23 19:09 Trildar

Ran into the same issue on WSL2 (Ubuntu 22.04). The path was wrong and had to manually change it (tsserver and pyright) just like OP did. I also run the same configuration on windows 10 and it works without any problems.

powN1 avatar Dec 20 '23 21:12 powN1

@powN1 Did you have npm installed on Windows? Did you also have it installed in WSL? If you had it installed in both, does which npm give you the one installed in WSL?

Trildar avatar Dec 20 '23 21:12 Trildar