There doesn't appear to be support for multiple environments, e.g. two independent environments both using the same version, similar to how virtualenv works.
Are there any plans to add support for this, and any known workarounds?
One use case where this would be very helpful is here
Perhaps @ljharb could comment on this?
I don't know what you're asking for - what do you mean by multiple environments? Do you mean, installing multiple copies of the same version of node with separate global namespaces and npms?
If that's what you want, why wouldn't you just have multiple copies of nvm in different $NVM_DIRs?
Oh interesting, so you can use NVM_DIR to create multiple environments. Ideally it'd be nice to see virtualenv for nvm, however I guess that's what nodeenv is for.
I'm still not sure what possible use case you'd have for multiple node environments of the same version. Projects should be self-contained such that the installed global modules don't matter.
This originally stemmed from here, but global modules didn't fix the problem either, so this can probably just be closed out.
Use case: There are still some packages that are preferred to be installed globally, like: Serverless (https://www.npmjs.com/package/serverless). When you have multiple Serverless projects, it becomes a necessity to run different Serverless versions against same Node engine version.
@juhamust That seems like a huge design flaw in Serverless, and not something that nvm should, or could easily, fix. I think the solution I suggested here is still the best.
Right. Thanks @ljharb for highlighting the alternative approach.
Another use case: I develop two vue.js projects, each in a different directory under $HOME.
Both of them were created with the same node.js version, however when each was created, a different version of the global @vue/cli library was globally installed. Therefore I need a different version of the global @vue/cli library installed for each of the two projects, in order to be able to maintain them in the future (note: I use the global @vue/cli library to to maintanance tasks on each of the two projects).
Now, it's been proposed in this thread that I could use a different value for $NVM_DIR. But please tell me: How can I ask bash to automatically set a different value to $NVM_DIR whenever I cd into each of the two dirrectories? Is that possible? Will it require a lot of extra work? Wouldn't it be easier and more practical if nvm offered me a way to achieve my desired result? (i.e. an environment with different global libraries for each of the two projects). Thank you.
@ljharb @juhamust
@akarelas while it is possible, I’d actually suggest never installing vue cli globally in the first place. Install it locally, and invoke it with npx - that way the version is automatically tracked per project.
Anything advising a global install is likely not advising a best practice.
I think it's the entire vue community that's suggesting installing @vue/cli globally... Could all of them be wrong? Never heard anyone propose a different method of working.
If they want a valid use case to be “different projects use a different CLI version”, then I’d say yes, they’re all wrong - i doubt they’re expecting anyone with that use case to both use a node version manager, and also use one that supports a feature (that doesn’t exist anywhere yet, afaik) to have distinct global package pools for the same node version.
I'll answer more completely later.
But as for the feature you talk of, the one whose existence anywhere you doubt, indeed exists somewhere: plenv. And maybe in other places too. Search for this line in that page: plenv install 5.18.1 -Dusedtrace --as 5.18.1-dtrace ...where you see a new with the same version of perl be compiled, but in a different directory, and with a new alias (5.18.1-dtrace). I've tried it myself and it works, even if the compile options are the exact same. And, even though I don't know Python, @foxx mentions python also has the same, with this sentence: "e.g. two independent environments both using the same version, similar to how virtualenv works."
Sorry, I meant, exists anywhere in the JS ecosystem :-)
Some vue people I asked agree with you, that installing vue/cli locally and calling it with npx is a good way to work.