Support multiple installations

[coreybutler]

Feature request ahead...

It'd be really useful to have more support for multiple installations, or at least some sort of specification that would allow the community to better support this. There are many module developers who need to test against different versions of node... the simplest use case being tests against the latest stable and the latest dev branches.

The community has produced n, nvm, nvmw, nodist, and other modules to support this... and they're breaking because the installation process continually changes and the module maintainers are moving to other projects. This whole thing is especially painful on Windows.

Since this is a common need across all operating systems, it seems like the standard for handling multiple installations should come from the top.

[OrangeDog]

Module developers should be capable of using NODEDIR and git, where it's very easy to switch a single node installation to different branches.

[jbergstroem]

I'm kind of fighting with whether this is core's problem or not. Python has respected its own "problem" by introducing pycache directories (vs pyc) and I think language/package managers in general should at least consider this as part of its specification, the same way inter-dependencies would be.

Not sure if it should go further than this though. I agree with @OrangeDog wrt the feasibility of managing multiple node environments with symlinks and env variables.

[coreybutler]

Please note I was suggesting the "standard" or spec of sort come from the top. If the solution did too, that would be nice... but there is a community of smart developers capable of following specs.

@OrangeDog - Not sure I'm following the context regarding NODEDIR. If that's an environment variable, it is not one I see on my Win8.1 dev station or my Linux installs. The specific use case I personally have in mind is rapidly testing module code, for example, against 0.10.26 and 0.11.x.

To elaborate, I've been using nvmw to control my environment. I run my unit tests, then switch the environment and run the same tests in the 0.11.x environment. The nvmw utility recently broke because it controls where node instances are installed and updates references to the appropriate installation directory. That's fine, but it installed node and npm separately, because that's how it was originally setup. The v0.10.30 npm is packaged in the Windows msi. This new approach broke the nvmw module. Again, it is something that developers can work around... if they know about it. The author of nvmw flat out stated he had no idea how to work around these changes... so the tool is pretty much useless going forward.

At the end of the day, I'm not certain if this is necessarily a core responsibility or not, but I agree with the feasibility @jbergstroem suggests with symlinks and env variables... as long as that information is known.

[OrangeDog]

NODEDIR tells npm where the version of node is that it should be building things against, instead of the version of node that you're using to run npm. It is optional and thus not set by default.

[coreybutler]

@OrangeDog - Is that documented somewhere? I'm surprised this is news to me.

[trevnorris]

This isn't going to be added to core. If you want to test a module against a specific built version of node then first you're definitely in the minority. Anyways, here are the commands:

Build a module using a custom built version of node:

$ /path/to/nodedir/node $(which node-gyp) rebuild --nodedir=/path/to/nodedir/

Installing a module using a custom build:

$ /path/to/nodedir/node $(which npm) --nodedir=/path/to/nodedir/ install <module>