Nvm-windows: reinstall-packages-from-version is wanted

[rawbin-]

reinstall-packages-from-version is wanted

switching node version needs reinstallation of all packages in the most case

[thenitai]

Totally agree. Coming from NVM on the Mac this is a must have 👍

[coreybutler]

This won't be added, but there is a proposal for a way to accomplish this at the discretion of the developer.

Why Not?

NVM4W and nvm have a similar name (a retrospective mistake on my part), and both are capable of switching versions. That's where the similarities end (NVM4W is philosophically more aligned with n). nvm for macOS enforces a workflow on the developer. NVM4W provides a more minimalistic approach, focusing on node version management, not npm management. NVM4W leaves workflow customization to the end user... because a) it's not hard, and b) it's very opinionated.

The statement "switching node version needs reinstallation of all packages in most cases" is unsubstantiated. This doesn't mean it's not true, but there aren't any stats to back this claim. There are plenty of use cases where this is not the case, such as developing original modules with forward/backwards compatibility.

Third, automating this process, either forcibly or by default, has a number of unintended consequences in a Windows environment. See the Roaming Profiles use case for an example.

Even if this were a non-default optional command, it still strays from node version management into npm management. This is an entirely different problem (and a much bigger problem).

How will this be accomplished if no feature is added to NVM4W?

There's a proposal to add hooks (similar to git-commit hooks). This would be an optional feature allowing developers to do whatever they want in a shell script/batch file. So, providing a hook like nvm-postinstall could easily accomplish this. This approach allows developers who want to reinstall packages to do so, without forcing this on people who don't.

That said, I recognize there are very popular approaches to managing the overall node environment. Using the hooks approach, I'm hoping to maintain a user-contributed repo of popular hook scripts.

All of this stuff will be coming in the next version, under a distinct new name, and it will be cross-platform. I have no ETA, as this falls to number 2 in my priority list, behind release of Fenix 3.0.0.