N: having a common global npm packages is not a good idea

[sandrodz]

Wouldn't it be better to seperate global packages of each version?

[nyxtom]

This is also an issue given that the npm version doesn't seem to be updated on n

[ljharb]

Yes, global modules should not be shared across node versions.

[troy0820]

I'm interested in this approach because nvm is shell specific right? n is not.

I'm not sure how to approach this.

Since the node version is activated across the user's platform the global module persists to be valid because node is using the version activated by n. N doesn't use a space where it can have individually global modules for each version.

If you are using a lot of global modules, Implementing that would create a lot of space where the global module is sourced to the same location across multiple version.

I am interested to see how you implemented it with nvm @ljharb

[ljharb]

Space is infinite and free, correctness is rare and expensive.

It's handled in nvm by each node version having its own entirely distinct global node_modules folder. In practice, nobody's complained of running out of disk space, especially because it's exceedingly rare nowadays to ever need a global module anyways (everything should generally be installed locally)

[troy0820]

It's handled in nvm by each node version having its own entirely distinct global node_modules folder.

I'm not sure that would work with n not being shell specific.

I'm curious to know why would this approach be wrong? If I downloaded a new version of node from int he internet and installed over top of the old one, the global modules still exist in the folder that npm dumps the global modules.

I didn't implement this, I just help maintain it but I know that nvm and n do it two different ways.

[ljharb]

@troy0820 because binary modules need to be recompiled on every version of node - sometimes patch, although usually just minor. The fact that that's how it works when you install node from source doesn't mean that's the way it should work.

At the very least, n should probably npm rebuild each of the installed global modules on every switch.

[drschwabe]

@ljharb dunno about that, cause that can take a while especially if you have said binary modules which need to recompile. It would take away from the convenience / speed of using n to switch versions so painlessly as is now (aside from, well - this issue of global modules).

Maybe for now could do a flag ie:

n 8 -rg

where -rg is for 're-install global modules'; in this example you switched from say node 6 to 8 which is accommodated by n as well as it will re-install your global modules as part of the switch.

But what would be better is simply a cache of the global modules which have been installed on each version; this way you wouldn't need to wait.

Perhaps the flag exampled above could in fact be the start point for making a cached version of said global modules; via symlink or some creative technique.

[adamreisnz]

From what I can see, global modules are being installed in their own node_modules folder now, e.g. /usr/local/n/versions/node/10.15.0/lib/node_modules instead of /usr/lib/node_modules, however this comes with a linking problem it seems, as those global modules cannot be found.

E.g.:

npm i -g pm2
pm2
-bash: pm2: command not found

[shadowspawn]

The folders under /usr/local/n/versions are the cached downloads which are used for reinstalls, or by n use. They are not used for global modules.

[jasonkarns]

Just a note that nodenv maintains distinct node_modules for each node version, as nvm does. But nodenv is not strictly "shell specific" as nvm is.

It's accomplished by shims existing in PATH, such that the node version is determined at invocation time (not ahead of time by an "activate" or "use" command).

https://github.com/nodenv/nodenv#how-it-works

[shadowspawn]

While it would be better for some users to have different global npm packages for each version of node, based on my current understanding I think for most users it would just be more complicated and/or slower for no immediate gain. New insights welcome.

I have not seen issues opened here due to problems caused by common global packages, but that could be because people for whom this is important just switch to another node manager.

I'll leave this issue open for now as there have been a couple of recent comments, and there are some alternative node managers mentioned for readers looking for this feature.

[ljharb]

It's better for all users, because it ensures correctness for all cases.

[shadowspawn]

@ljharb I agree to disagree
i.e. I respect your viewpoint and expertise and experience (nvm maintainer), but haven't changed my opinion at this point in time

[shadowspawn]

Added How It Works to README to clarify implementation