Contribution
Describe the user story
Can PNPM offer a way to opt out of the runtime management feature included in PNPM 10.14+? 🤔 My main reason for this is that many projects use PNPM purely as a package manager, in combination with other tools such as FNM, Mise, etc. to externally manage the runtime.
These external tools might choose to select the runtime according to devEngines.runtime which isn't PNPM specific (e.g., FNM has an issue for it: Schniz/fnm#1389), so if PNPM simultaneously does its own runtime resolution, there could be 2 instances of the runtime applicable to the project (one externally managed, and the other PNPM managed), and the runtime used by scripts (process.argv[0]) could differ according to how they're invoked (e.g, pnpm exec ... vs simply node ...).
Or in general, one should be able to specify devEngines.runtime without PNPM implications, in projects that don't use PNPM to manage the runtime version. I briefly discussed this on the PNPM Discord.
Aside: I'm unsure if this is a bug, but PNPM expects devEngines.runtime.version to be specified as a single SemVer (e.g., ^24.4.0), but not a SemVer range (e.g., >=24.0.0 <25.0.0) which is what the devEngines proposal allows (example below). If this is by design (and not a bug), I think PNPM should be able to ignore the SemVer range specified here (e.g., for non-PNPM purposes), so that pnpm install wouldn't produce warnings.
Example with ^24.0.0/>=24.0.0 <25.0.0.
With "devEngines": { "runtime": { "name": "node", "version": "^24.0.0", "onFail": "download" } }:
$ rm -r -f node_modules pnpm-lock.yaml ; pnpm install
Packages: +1
+
Progress: resolved 1, reused 1, downloaded 0, added 1, done
devDependencies:
+ node 24.11.1
Done in 2.1s using pnpm v10.24.0
But with "devEngines": { "runtime": { "name": "node", "version": ">=24.0.0 <25.0.0", "onFail": "download" } } which should be equivalent:
$ rm -r -f node_modules pnpm-lock.yaml ; pnpm install
Packages: +2
++
Progress: resolved 2, reused 2, downloaded 0, added 2, done
WARN Failed to create bin at ~/project/node_modules/.pnpm/node@20.19.6/node_modules/node/node_modules/.bin/node. ENOENT: no such file or directory, open '~/project/node_modules/.pnpm/node@20.19.6/node_modules/node/bin/node'
WARN Failed to create bin at ~/project/node_modules/.bin/node. ENOENT: no such file or directory, open '~/project/node_modules/.pnpm/node@20.19.6/node_modules/node/bin/node'
WARN Failed to create bin at ~/project/node_modules/.bin/node. ENOENT: no such file or directory, open '~/project/node_modules/node/bin/node'
devDependencies:
+ node 20.19.6
╭ Warning ───────────────────────────────────────────────────────────────────────────────────╮
│ Ignored build scripts: node. │
│ Run "pnpm approve-builds" to pick which dependencies should be allowed to run scripts. │
╰────────────────────────────────────────────────────────────────────────────────────────────╯
Done in 673ms using pnpm v10.24.0
Describe the solution you'd like
A workspace setting to opt out of the runtime being PNPM managed, for when a project uses PNPM purely for package management, and not for runtime management.
The runtime management feature should of course be enabled by default (opt out setting: false by default) for backward compatibility, and projects can disable the feature (opt out setting: true) if needed.
I also think that if a project switches from its runtime being PNPM managed (opt out setting: false) to externally managed (opt out setting: true), pnpm install should remove the previously installed PNPM managed runtime (if applicable) from the project (node_modules and the lock file).
Describe the drawbacks of your solution
No response
Describe alternatives you've considered
No response
Contribution
Describe the user story
Can PNPM offer a way to opt out of the runtime management feature included in PNPM 10.14+? 🤔 My main reason for this is that many projects use PNPM purely as a package manager, in combination with other tools such as FNM, Mise, etc. to externally manage the runtime.
These external tools might choose to select the runtime according to
devEngines.runtimewhich isn't PNPM specific (e.g., FNM has an issue for it: Schniz/fnm#1389), so if PNPM simultaneously does its own runtime resolution, there could be 2 instances of the runtime applicable to the project (one externally managed, and the other PNPM managed), and the runtime used by scripts (process.argv[0]) could differ according to how they're invoked (e.g,pnpm exec ...vs simplynode ...).Or in general, one should be able to specify
devEngines.runtimewithout PNPM implications, in projects that don't use PNPM to manage the runtime version. I briefly discussed this on the PNPM Discord.Aside: I'm unsure if this is a bug, but PNPM expects
devEngines.runtime.versionto be specified as a single SemVer (e.g.,^24.4.0), but not a SemVer range (e.g.,>=24.0.0 <25.0.0) which is what thedevEnginesproposal allows (example below). If this is by design (and not a bug), I think PNPM should be able to ignore the SemVer range specified here (e.g., for non-PNPM purposes), so thatpnpm installwouldn't produce warnings.Example with
^24.0.0/>=24.0.0 <25.0.0.With
"devEngines": { "runtime": { "name": "node", "version": "^24.0.0", "onFail": "download" } }:But with
"devEngines": { "runtime": { "name": "node", "version": ">=24.0.0 <25.0.0", "onFail": "download" } }which should be equivalent:Describe the solution you'd like
A workspace setting to opt out of the runtime being PNPM managed, for when a project uses PNPM purely for package management, and not for runtime management.
The runtime management feature should of course be enabled by default (opt out setting: false by default) for backward compatibility, and projects can disable the feature (opt out setting: true) if needed.
I also think that if a project switches from its runtime being PNPM managed (opt out setting: false) to externally managed (opt out setting: true),
pnpm installshould remove the previously installed PNPM managed runtime (if applicable) from the project (node_modulesand the lock file).Describe the drawbacks of your solution
No response
Describe alternatives you've considered
No response