Scope of global modules

[marcelklehr]

Should global node modules by installable and usable only per specific version or should it be possible to install them per major version, for example?
See also jasongin/nvs#21 (and jasongin/nvs#23 (comment))

[coreybutler]

This has been a hotly debated subject between several NVM4W users, as has a shared global node_modules directory. The arguments I've heard for specific versioning focus on native module dependencies tied to a specific version of Node. The arguments I hear in favor of handling a major version is the overall footprint on the developer's machine can be substantially smaller, especially when the user has a lot of minor/patch versions installed.

An idea I've been mulling over is symlinking global node_modules in an effort to reduce footprint size while still providing users the ability to override with whatever they want. Essentially, there'd be one directory to store every global module (by version). Each version would essentially get a hash map of which directories need to be present in their global installation, leveraging symlinks to make them available in the manner node expects. The further down that train of thought I go, the more I hate it. It feels like a rabbit hole, and it seems like it would require an npm shim for handling things like npm i -g whatever.

[ljharb]

global modules should not be shared across node versions, period. One big reason is native/binary/compiled modules - they'd need to be recompiled every time. Another would be a module that autodownloads something based on the node version, like phantomjs.

In other words, global modules must always be freshly installed for each version of node, or else things can break in surprising ways. This is why nvm has nvm reinstall-packages instead of sharing global modules across node versions.

[coreybutler]

@ljharb - I totally agree re: shared global modules. This is an argument/request I've heard from a substantial number of users though... they made a compelling argument about module redundancy, and in some cases 10-20GB of data could be cut down to 1-2GB. I ultimately vetoed it in NVM4W for the exact same reason. I felt the arguments were understandable, but ultimately a problem of workspace management, not version management (yes, I'm splitting hairs). The point here is nvm has a solution for this, and those kinds of use cases should be documented to help educate users when they encounter these issues.

Also, I think global modules actually need to be considered not just at the patch level, but at the architecture level. One mistake I made in NVM4W was having a global modules directory within each Node version, i.e. a directory like 6.9.2/node_modules. This caused problems for users of native modules who had different compilation experiences when switching between 32 and 64 bit versions of node.

[ljharb]

That's true - although in nvm the architecture never changes on the same machine, so it never comes up.

[marcelklehr]

Consider me convinced :) Good to have a discussion about it, though!