Support pnpm

[gunta]

Support pnpm installation, since it can work independently from Node.js version.

https://pnpm.io/installation

[memark]

Sounds like that would be the job for a separate tool, no? Something like pnpmenv.

[jasonkarns]

What's the request here? The referenced installation page says pnmp can be installed even without node so it doesn't sound like nodenv needs to do anything to "support pnmp". It can also be installed via homebrew (also not affected by nodenv). Or it can be installed via npm globally, which would (with nodenv) mean it's installed within the chosen node version.

Sounds like there's nothing to do here?

[gunta]

The referenced installation page says pnmp can be installed even without node so it doesn't sound like nodenv needs to do anything to "support pnmp". It can also be installed via homebrew (also not affected by nodenv). Or it can be installed via npm globally, which would (with nodenv) mean it's installed within the chosen node version.

Given that it can be installed in multiple ways, yes, a separate tool like pnpmenv would be ideal.

The request here is:

• Allow multiple pnpm versions to be installed
• Automatically change to the pnpm version used in the current folder, based on package.json's
  "packageManager": "pnpm@version" contents.

[jasonkarns]

A wholly new tool is outside the scope of this project, though I'd still like to further understand the end goal. I think I'd have to understand how pnpm operates to fully grasp what role nodenv could play. (Does pnpn maintain state outside its installation directory? If it does, (eg to share packages, etc) then you'd have those packages shared across node versions which may not work.)

Digging more, would you expect the version of pnpm to change in concert with a particular node? That is, in any given project, I assume you would want a single node and a single pnpm version to be active, yes? I'm assuming that having pnpm installed outside of node and allowing it to share state across node versions would be problematic?

ie, "in this project, we want node 14 and pnpm 6; in another project we want node 16 and pnpm 7" ?

What's the use case for wanting different versions of pnpm? Are there reasons one can't/shouldn't keep up on the latest pnpm?

Potential approach:
Back in the day, when npm 2 and 3 were fairly incompatible with each other and switching projects required switching npms, a "simple" solution was to pin a version of npm to a particular node.

Example, using contrived version numbers:

1. install a node (say v16) nodenv install 16.19.1
2. install desired pnpm version (say v6) npm i -g pnpm@6
3. rename that node: cd $(nodenv root)/versions; mv 16.19.1{,+pnpm6}
4. install another node (say v16 again) nodenv install 16.19.1
5. install different pnpm version npm i -g pnpm@7
6. rename that node: cd $(nodenv root)/versions; mv 16.19.1{,+pnpm7}

Doing that will give you two nodes, with different versions of pnpm (installed as global modules within their respective nodes). Renaming them allows you to select 16.19.1+pnpm6 or 16.19.1+pnpm7 as your NODENV_VERSION (or in .node-version) such that switching projects will activate the appropriate pnpm.

[yshrsmz]

It's 2024, and now we can just use corepack for this, right?