Node.js issues after installing through LSP-copilot

[gemisigo]

I've tried to follow the simple installation guide for LSP-copilot and the problems started at step one. Installing LSP was done successfully, but after installing LSP-copilot I faced a warning stating that:

Could not start LSP-copilot due to not being able to resolve suitable Node.js runtime on the PATH. Press the "Download Nodejs" button to get required Node.js version (note that it Will be used only by LSP and Will not affect your system otherwise).

Obviously, I chose "Download Node.js" which downloaded something and put it into "C:\Users\gemis\AppData\Local\Sublime Text\Package Storage\lsp_utils". Before I could restart Sublime Text, it popped an error dialog with this:

Failed to start LSP-copilot - disabling for this window for the duration of the current session.
Re-enable by running "LSP: Enable Language Server In Project" from the Command Palette.

--- Error: ---
Failed resolving Node.js Runtime. Please check in the console for more details.

Trying the suggested "LSP: Enable Language Server In Project" will only resurrect the error dialog. I guess something with path is not set properly but I have no idea what. Any hints?

[rchl]

Please check in the console for more details.

[gemisigo]

Sure, here it comes:

[lsp_utils] Downloading Node.js 16.15.0 from https://nodejs.org/dist/v16.15.0/node-v16.15.0-win-x64.zip
--- lsp_utils Node.js resolving start ---
Resolving Node.js Runtime in env PATH for package LSP-copilot...

• Failed: "node" binary not found
  Resolving Node.js Runtime from lsp_utils for package LSP-copilot...
• Binaries check failed: "node" binary not found
• Error resolving Node.js version:
  v16.15.0
  --- lsp_utils Node.js resolving end ---
  Unable to start subprocess for LSP-copilot
  Traceback (most recent call last):
  File "C:\Users\gemis\AppData\Roaming\Sublime Text\Installed Packages\LSP.sublime-package\plugin/core/windows.py", line 239, in start_async
  if plugin_class.needs_update_or_installation():
  File "C:\Users\gemis\AppData\Roaming\SUBLIM1\Packages\LSP_UT1\st3\lsp_utils_client_handler\abstract_plugin.py", line 101, in needs_update_or_installation
  server = cls.get_server()
  File "C:\Users\gemis\AppData\Roaming\SUBLIM1\Packages\LSP_UT1\st3\lsp_utils\npm_client_handler.py", line 130, in get_server
  'skip_npm_install': cls.skip_npm_install,
  File "C:\Users\gemis\AppData\Roaming\SUBLIM1\Packages\LSP_UT1\st3\lsp_utils\server_npm_resource.py", line 34, in create
  node_runtime = NodeRuntime.get(package_name, storage_path, required_node_version)
  File "C:\Users\gemis\AppData\Roaming\SUBLIM1\Packages\LSP_UT1\st3\lsp_utils\node_runtime.py", line 58, in get
  cls._node_runtime = cls._resolve_node_runtime(package_name, storage_path, required_semantic_version)
  File "C:\Users\gemis\AppData\Roaming\SUBLIM1\Packages\LSP_UT1\st3\lsp_utils\node_runtime.py", line 119, in _resolve_node_runtime
  raise Exception('Failed resolving Node.js Runtime. Please check in the console for more details.')
  Exception: Failed resolving Node.js Runtime. Please check in the console for more details.

Does this help?

[rchl]

What's the directory structure within C:\Users\gemis\AppData\Local\Sublime Text\Package Storage\lsp_utils\node-runtime and subdirectories? Can you screenshot it?

[gemisigo]

Here it is:
node-runtime_contents.zip

[rchl]

Are you able to manually start node-runtime/node/node.exe?

[gemisigo]

That path is invalid, 16.15.0 is between node-runtime and node.

C:\Users\gemis\AppData\Local\Sublime Text\Package Storage\lsp_utils\node-runtime\16.15.0\node

node.exe
Welcome to Node.js v16.15.0.
Type ".help" for more information.

I can also start it from lsp_utils using node-runtime\16.15.0\node\node.exe.

[rchl]

Kinda running out of ideas. :)

Maybe you can add some logging to lsp_utils. You'd have to locate the node_runtime.py in the Packages folder (in C:\Users\gemis\AppData\Roaming\Sublime Text\Data\Packages\lsp_utils\st3\lsp_utils\node_runtime.py or something like that) and add

diff --git a/st3/lsp_utils/node_runtime.py b/st3/lsp_utils/node_runtime.py
index 841df0c..ff876d3 100755
--- a/st3/lsp_utils/node_runtime.py
+++ b/st3/lsp_utils/node_runtime.py
@@ -229,6 +229,10 @@ class NodeRuntimeLocal(NodeRuntime):
         self._additional_paths = [path.join(self._node_dir, 'bin')]
         self._install_in_progress_marker_file = path.join(self._base_dir, '.installing')
         self._resolve_paths()
+        print('PATHS')
+        print(self._base_dir)
+        print(self._node)
+        print(self._npm)

     # --- NodeRuntime overrides ----------------------------------------------------------------------------------------

[gemisigo]

Kinda running out of ideas. :)

I've started with none :D

These seem to be right (at least to me):

PATHS
C:\Users\gemis\AppData\Local\Sublime Text\Package Storage\lsp_utils\node-runtime\16.15.0
C:\Users\gemis\AppData\Local\Sublime Text\Package Storage\lsp_utils\node-runtime\16.15.0\node\node.exe
C:\Users\gemis\AppData\Local\Sublime Text\Package Storage\lsp_utils\node-runtime\16.15.0\node\node_modules\npm\bin\npm-cli.js

The rest, not so much:

--- lsp_utils Node.js resolving start ---
Resolving Node.js Runtime in env PATH for package LSP-copilot...

• Error resolving Node.js version:
  v16.15.0
  Resolving Node.js Runtime from lsp_utils for package LSP-copilot...
• Error resolving Node.js version:
  v16.15.0
  --- lsp_utils Node.js resolving end ---
  Unable to start subprocess for LSP-copilot
  Traceback (most recent call last):
  File "C:\Users\gemis\AppData\Roaming\Sublime Text\Installed Packages\LSP.sublime-package\plugin/core/windows.py", line 239, in start_async
  if plugin_class.needs_update_or_installation():
  File "C:\Users\gemis\AppData\Roaming\SUBLIM1\Packages\LSP_UT1\st3\lsp_utils_client_handler\abstract_plugin.py", line 101, in needs_update_or_installation
  server = cls.get_server()
  File "C:\Users\gemis\AppData\Roaming\SUBLIM1\Packages\LSP_UT1\st3\lsp_utils\npm_client_handler.py", line 130, in get_server
  'skip_npm_install': cls.skip_npm_install,
  File "C:\Users\gemis\AppData\Roaming\SUBLIM1\Packages\LSP_UT1\st3\lsp_utils\server_npm_resource.py", line 34, in create
  node_runtime = NodeRuntime.get(package_name, storage_path, required_node_version)
  File "C:\Users\gemis\AppData\Roaming\SUBLIM1\Packages\LSP_UT1\st3\lsp_utils\node_runtime.py", line 58, in get
  cls._node_runtime = cls._resolve_node_runtime(package_name, storage_path, required_semantic_version)
  File "C:\Users\gemis\AppData\Roaming\SUBLIM1\Packages\LSP_UT1\st3\lsp_utils\node_runtime.py", line 119, in _resolve_node_runtime
  raise Exception('Failed resolving Node.js Runtime. Please check in the console for more details.')
  Exception: Failed resolving Node.js Runtime. Please check in the console for more details.

But this error message is a bit different than the previous one. What does this Resolving Node.js Runtime in env PATH for package LSP-copilot... mean? I've tried adding the folder where the node.exe resides to the PATH but it does not seem to make any difference.

[rchl]

It appears that running node.exe --version on your system results in Node providing a correct answer (v16.15.0) but binary returning an error exit code.

I remember there was someone with an issue like that on Windows where he modified some registry value so that all "shell" invocations were wrapped into another script that was failing. It seems like a similar issue.

[rchl]

Found it on Discord:

I have an AutoRun script that checks whether a shell instance (cmd.exe) is interactive - if it isn't, that script exits with error code 1 that error code triggered subprocess.CalledProcessError even though node --version returned 0

[rchl]

I will try to address it in #101 anyway, even if it appears to be an Windows configuration issue or some third-party software causing issues.

[predragnikolic]

I cannot reproduce on Windows 11 in my VM.

I tried a couple of things.
Having Node available on the system globally,
than uninstalling it and seeing if it would cause such issues.
Messing around lsp_utils settings... tried all variations :) for "nodejs_runtime", ["system", "local"] | ["local"] | [],
Enabled local_use_electron ...

Still nothing.

[gemisigo]

It appears that running node.exe --version on your system results in Node providing a correct answer (v16.15.0) but binary returning an error exit code.

I remember there was someone with an issue like that on Windows where he modified some registry value so that all "shell" invocations were wrapped into another script that was failing. It seems like a similar issue.

Is there a way to check if this is the reason in my case? I don't remember tinkering with the registry. I've tried to find the part where this goes awry, and located version, error = run_command_sync([self._node, '--version'], extra_env=self.node_env()) at line 163 in node_runtime.py. So I tossed my own two cents, er... I mean lines at the problem, and added the following

        print("gem's debug - version: [", version, "]")
        print("gem's debug - error: [", error, "]")

right after it just to see what line 163 puts into those two variables and it was very interesting. I'm pretty sure that what it printed

gem's debug - version: [ ]
gem's debug - error: [ v16.15.0 ]

is kinda unexpected by the code trying to interpret values in version and error. It seems that those two are swapped. Not that swapping them again solves anything (I tried out of curiosity, and I saw it kill the cat), for it still throws the same error message, as the value of error is not None but two spaces.

[rchl]

The code is correct. Your Windows is doing something that is not correct.

As I've quoted in #100 (comment), some third party apps can influence the exit code of the command and turn a successful response into an error response even though the app itself (node in this case) returned a successful response.

I think my linked change should fix it because we won't execute it in "shell" mode anymore and I think this issue only affects shell mode.

We'll have to see once I merge my fix.

[rchl]

I've merged my fix. In an hour or more the update should be available and it will be possible to manually trigger it with Package Control: Satisfy Dependencies in the Command Palette.

[gemisigo]

The code is correct. Your Windows is doing something that is not correct.

I haven't said it is not. I merely stated that something strange happens, which might very well be the result of Windows doing something bad. I highly doubt that swapping two variables could hide in shadows for any length of time, provided that the run_command_sync is run multiple times, and the caller always takes the two values in the same exact order, so I guess the code is correct. But for some reason in this case its results are screwed up. And I don't think it's something you should 'fix', but I don't know how to figure out what's wrong with Windows without your help.

Also, my bad, it's not two spaces, but an empty string (which should evaluate to False but is definitely not None).

[rchl]

I'm only doing this change because it should make things slightly more efficient on Windows. The fixing of this issue (hopefully) will be just a positive side effect.

[gemisigo]

And here I was thinking you wanted to help me 😛 Nevertheless, this indeed made the problem go away, so thank you very much, @rchl.

[rchl]

I don't like doing workarounds for seemingly broken configurations :)

You should figure out your issue anyway as it might affect other things (even within ST). It looks like non-interactive shell invocations return exit code for some reason even though the executable returns a successful response.