Environment managers like Python's venv/virtualenv, Ruby's rvm, and Node's nvm make it easy for users to install and configure a runtime's versions and constituent components. Each virtual environment can support a specific runtime version and configuration and an independent set of global modules. In fact, some runtimes, such as .NET Core, can bundle and refer to a specific runtime configuration for each app. To summarize, environment managers enable developers to:
- install the runtime with a specific configuration.
- change runtime configurations for test and other needs.
- manage runtime and component updates.
The usefulness and demand for environment managers for Node.js is clear from the many managers already available today, including:
A full list including different capabilities and semantics is here - props to @jasongin.
But the number of configuration options and operating environments for Node.js continues to multiply, and each of the available managers tackles only some of these options, and only in certain environments. For example, some work on Windows, some only on Linux. Some use shell script, some use JavaScript, and some use Go. Some support different environments per directory/project, and some only support an environment per shell or user. It would be simpler for developers to have at least one manager which supported all of Node.js's supported platforms and potential configurations.
In addition, how runtime configuration is specified and implemented requires close collaboration and feedback between those responsible for the runtime itself and those responsible for its manager. For example, if a developer wants to utilize LibreSSL instead of OpenSSL within an app or module, the runtime itself must accomodate this and provide a way for runtime managers to determine and set that configuration. Similarly, if developers want ways to specify alternate JS runtimes, the runtime itself must support this and provide an external configuration mechanism. It would be easiest for the runtime and its manager(s) to be developed in close collaboration.
Finally, while having many unofficial tools and options arguably provides greater flexibility, it also places a significant burden on downstream developers, who must choose and learn different tools and their semantics for different use cases. For example, a developer wanting to test an app on Windows and Linux must use a different env manager for each. If they encounter trouble, they must determine whether this particular manager modifies the PATH variable, symlinks into existing directories, or some other mechanism. Developers would be well served by at least one environment manager which works and behaves the same way everywhere.
To achieve these goals of a) a manager which supports all of Node's supported platforms and configurations; b) close collaboration between runtime and runtime manager development; and c) better useability for downstream developers, we should bring together maintainers of these disparate projects and try to build at least one official Node environment manager with the best ideas and implementations from each project.
To achieve this, let's designate a repo as a workspace and create an informal or formal working group to pursue the goals described above. Let's invite maintainers and stakeholders from existing projects and Node.js core to initial discussions and meetings and therein agree on goals and roadmap. And then let's collaborate to refine the result and add more options based on our users' needs.
Node's guidelines state that: Working Groups are not formed to begin a set of tasks but instead are formed once that work is already underway and the contributors think it would benefit from being done as an autonomous project.
In the case of Node environment and version managers, the work is well underway as evident from the above list of options, so it seems reasonable to create an official working group now.