[BUG] node v18.16.0 (64-bit) is not installed

[Kochise]

Issue:

Installation on Windows

How To Reproduce:

1. https://github.com/coreybutler/nvm-windows/releases/download/1.1.11/nvm-noinstall.zip
2. cmd
3. nvm list available
4. nvm install lts
5. nvm list
6. nvm use 18.16.0
7. nvm list

Expected Behavior:

Nvm installed

Windows 10 22H2, admin rights

[Tester798]

Did you try to remove by hand your previous symlink? It wasn't working for me too when symlink was pointing to non-existent folder. After removing the symlink, nvm use ... started to work for me again.

[coreybutler]

Please run nvm debug. There may be a problem with the PATH.

[Kochise]

Please run nvm debug. There may be a problem with the PATH.

Done that :

C:\Program Files\nodejs points C:\Program Files\v16.13.0 which is the version that I share/use here :

https://github.com/Kochise/win_portable/tree/master/Coding/nvm/nvm_cmd.bat loads it into a temporary session's environment variables (to keep it portable).

Same for https://github.com/Kochise/win_portable/blob/master/Document/texmaker/texmaker.bat

Then of course https://github.com/wenuam/wm_doc_latex as well.

I'm indeed a bit dubious about the C:\Program Files\v16.13.0 link....

Anyway, while the problem probably lies on my side, could you yet avoid the "symlink" stuff and make the use of any installed version more "straightforward" ?

I mean, opening a terminal, typing nvm use xx.yy should just set a NVM_VER environment variable "locally" and the "local" PATH variable with the appropriate path to the selected version, perhaps output a ready to launch nvm_use_xx_yy.bat file to do just that before needing to run a specific version.

Especially due to the changes and evolution with subsequent nvm folder structure, one may want to keep several installations in parallel for backward compatibility, but want to switch from version more easily and even run them concurrently (using the sessions' local settings).

Regards.

[coreybutler]

Hmm, the debug tool needs to account for the cmd.exe in Windows 10. Unfortunately, shell detection on Windows has to use the title of the open window to determine which shell is running. In this case, the problem indicating the shell isn't supported is a false positive, but the symlink problem is valid.

I really don't know what's going on with this environment because it seems like you have quite a few customizations. The original post mentioned having admin rights, but the debug contradicts this. The settings file is supposed to exist in the NVM root, but your configuration has it on a different drive.

If no symlink exists, then Node won't be found when attempting to use it. The list will still have it, because it's not reading the symlink when it looks for versions. It looks in the NVM_HOME path.

While it would be possible to change an environment variable as you suggested, the PATH isn't guaranteed to respect changes without a restart of the terminal (whereas symlinks are respected). This approach requires the PATH be reset each time you want to use a new version (I call this PATH thrashing). Every time the PATH is reset, you run the risk of corrupting it. This is particularly difficult when users have a very long PATH. I remember one test case (years ago) quite distinctively when the Node version went from vX.X.X to vXX.X.X. That single extra character exceeded the maximum character limit for the PATH variable, causing the update to clear the entire PATH. The system became inoperable.

As for running a batch file, that isn't practical in enterprise environments because you can't code-sign a batch file without corrupting it. No code signing means the program will typically be blocked and is often flagged by antivirus.

Your last comment doesn't really make sense to me, because the NVM folder structure doesn't change (unless you're referring to new Node installations). NVM4W stores all installed versions in the NVM_HOME, as illustrated here:

The core premise of this project is to maintain a system-wide version, not per shell. You can still technically use a different version if you want by specifying it directly, as mentioned here. If you're coming from nvm-sh, which is per shell, this may feel verbose. It's something I've taken into consideration. It will not be added to NVM4W, but there are plans to accommodate this scenario in Runtime.

I've been able to verify the lts installation on several different Windows computers, so I do think this is an isolated scenario and not a bug in NVM4W. I'm going to close this issue, but I am open to discussing this further if you want to start a discussion.

[Kochise]

Hi, thank for having looked into the issue.

While I do have admin right over the machine, I avoid using it since you provide elevation tricks already.

I avoid changing the system' PATH, that's why I make/use bat files to perform a per-session modification of environment variables.

That limit the risks, and you can perform as many checks as you want before making any change, even though they won't put the system in jeopardy.

About the folder structure, yeah, I meant Node, not nvm, my bad.

As I told you, nothing prevents you to create a nvm batch runner file for each version you install : just create inside the nvm folder with a nvm_xx_yy_cmd.bat name that will open a prompt configured with all the right settings, copying the system's PATH and appending the NVM_HOME variable if necessary.

Yes the buddies will have to launch their soft by hand from within this per-session configured terminal, but at least you'll get rid of the elevation problems, folder access rights, symlink issues, code signing things, system PATH override, etc.

The best would be to add some tricks to the generated bat file so that is run without parameter, it tries to start a exe with the same %~n0 name in the same folder (just copy and rename the generated bat inside the target exe's folder to have a replacement runner).

I did this with https://github.com/wenuam/wm_lng_python/blob/main/pyrun.bat#L74

You can also detect the input parameter %~x1 as being an exe and set the environment variables before running it.

I did this with https://github.com/wenuam/wm_doc_latex/blob/main/pdflatex_compile.bat#L49

Hence you just have to drag'n drop your exe to one of the generated bat file to set its specific settings then run the exe inside a "containerized" environment.

Really, you should think in a more "portable" way to avoid changing the user's machine settings, especially in an enterprise environment.

While not perfect (far from it) the cmd sessions offers you a few tricks up its sleeves to do some kind of magic in that regard.

Regards.

[coreybutler]

What you're suggesting is essentially a shim strategy. This approach was considered when the project first launched, but was rejected due to the state of Windows at the time. Back then, it was really hard to pass the user/security context from a shim to the target executable. Windows has evolved a lot since then.

I understand the desire for portability. It is a factor being taken seriously for Runtime (NVM4W's successor), but it's not a priority for this project. This is, in part, because the design goal of this project was always to be a system-wide version manager, not a per-shell version manager. I recognize the need/benefit, but I'm prioritizing my time for Runtime, as a replacement for NVM4W.

[Kochise]

Could you try https://github.com/wenuam/wm_doc_latex/blob/main/nvm/nvm_run_16.13.0.bat

Just copy it inside your NVM_HOME folder containing the installations, rename it with the version you target (ie nvm_run_5.1.0.bat).

You can of course duplicate it for the various versions inside the NVM_HOME folder.

If you run it 'dry', it'll open a per-session cmd window into which you can type node (or set to check environment variables).

If you add parameters or drag an executable on the batch file, it'll run the parameters/file with the version targeted by the batch file.

To ease things for executable running with a specific version, just create a link to the batch file and add the executable as parameter.

Tell me what's missing to improve the experience of nvm in a 'portable' fashion.

Regards.

[coreybutler]

Tell me what's missing to improve the experience of nvm in a 'portable' fashion.

What's missing is time. See NVM4W Feature Freeze. My primary objective is to build a better tool with a more sustainable model. That's why we're building Runtime.

[Kochise]

Ok, I'll stay with my "hack" provided nvm can at least download and unpack selected version.

Thank you.