DRAFT: Use least-privilege install and use strategy by default.

[BurtHarris]

trafficstars

Default to a per-user install Move the default NVM_SYMLINK into NVM_HOME Don't mix per-user and system install Switch to use of NTFS Junction points

[BurtHarris]

The biggest question may be when symbolic links should be used over junctions.

[BurtHarris]

I am aware it currently gets:

Runtime error (at 28:55): Internal error: An attempt was made to expand the "app" constant before it was initialized.

[coreybutler]

While I appreciate the PR, I don't want to make changes to the symlink structure (i.e. no junctions) right now. The main reason is I'm trying to feature-freeze NVM4W as much as possible while I work on Runtime, the successor project (see https://github.com/coreybutler/nvm-windows/discussions/565).

I'm not fundamentally opposed to junctions, but they don't work across mapped network drives. There are quite a few organizations using mapped network drives (think hot-desking), so this could be a pretty big breaking change. In Runtime, I'm experimenting with a combination of symlinks, junctions, and even a shim to streamline this process.

Defaulting to a per-user install also presents challenges to organizations using this on shared servers, which is a scenario I faced doing custom implementations for clients. Ultimately, I think a per-user install is the right direction to go, but that should also be introduced in a new major version. In Runtime, I'm attempting to have a reconfigurable installation, meaning I'm trying to add features that will let users toggle their version management strategy to best suit whatever they're doing. That has to be in the app though, not in an installer.

Bottom line: I think there are some good ideas in this PR and I appreciate the effort, but I think it needs to be introduced in a way where a breaking change is less impactful. There are many other changes that fall into this category, which is why I decided to start efforts on Runtime.

I'm not going to close this PR, but I am going to label it in a way where it will resurface with Runtime.

[BurtHarris]

Thanks for explaining, Corey.

And I'm impressed you have enterprise use cases in mind for Runtime. I, too, once supported some large (and weird) deployment scenarios when working in the Microsoft Federal team. I'm retired from that world these days, and my life is much simpler.

I was also pondering if switching to junctions would call for a major version bump. Semantic versioning is only intended to cover public APIs, so it gets fuzzy, but I agree in spirit.

It does, however, give me another thought. The installer can be made to support both shared and per-user install scenarios, and the change could keep the shared-install nvm behavior unchanged. But if the install is run in per-user mode, the case for using junctions seems strong.

P.S. I trust you already know this, but here is a good read: even today, reasonable security policies require symlinks remain restricted on Windows. If you are targeting security-smart enterprises, they may still push back.

[github-actions[bot]]

This PR is stale because it has been open 45 days with no activity.

[minijus]

Would be lovely to have junction option (configurable via settings.txt). This would allow organisations to use nvm-windows with no need for elevated privileges.

Could solve: https://github.com/coreybutler/nvm-windows/issues/889