Using --reinstall-packages-from installs/enables Corepack

[jportner]

Operating system and version:

• macOS 15.3.1

nvm debug output:

nvm --version: v0.40.1
$TERM_PROGRAM: vscode
$SHELL: /bin/zsh
$SHLVL: 1
whoami: 'joe'
${HOME}: /Users/joe
${NVM_DIR}: '${HOME}/.nvm'
${PATH}: /opt/homebrew/opt/openjdk/bin:/opt/homebrew/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/bin:${NVM_DIR}/versions/node/v22.14.0/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/Library/Apple/usr/bin:/opt/homebrew/opt/openjdk/bin:/opt/homebrew/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/bin:${NVM_DIR}/versions/node/v22.14.0/bin:/opt/homebrew/opt/python@3.9/libexec/bin:/opt/homebrew/opt/python@3.9/libexec/bin
$PREFIX: ''
${NPM_CONFIG_PREFIX}: ''
$NVM_NODEJS_ORG_MIRROR: ''
$NVM_IOJS_ORG_MIRROR: ''
shell version: 'zsh 5.9 (arm64-apple-darwin24.0)'
uname -a: 'Darwin 24.3.0 Darwin Kernel Version 24.3.0: Thu Jan 2 20:24:23 PST 2025; root:xnu-11215.81.4~3/RELEASE_ARM64_T6031 arm64'
checksum binary: 'sha256sum'
OS version: macOS 15.3.1 24D70
awk: /usr/bin/awk, awk version 20200816
curl: /usr/bin/curl, curl 8.7.1 (x86_64-apple-darwin24.0) libcurl/8.7.1 (SecureTransport) LibreSSL/3.3.6 zlib/1.2.12 nghttp2/1.63.0
wget: not found
sed: /usr/bin/sed
cut: /usr/bin/cut
basename: /usr/bin/basename
rm: /bin/rm
mkdir: /bin/mkdir
xargs: /usr/bin/xargs
git: /usr/bin/git, git version 2.39.5 (Apple Git-154)
grep: /usr/bin/grep, grep (BSD grep, GNU compatible) 2.6.0-FreeBSD
nvm current: v22.14.0
which node: ${NVM_DIR}/versions/node/v22.14.0/bin/node
which iojs: iojs not found
which npm: ${NVM_DIR}/versions/node/v22.14.0/bin/npm
npm config get prefix: ${NVM_DIR}/versions/node/v22.14.0
npm root -g: ${NVM_DIR}/versions/node/v22.14.0/lib/node_modules

nvm ls output:

        v16.0.0
        v16.1.0
        v18.0.0
        v18.1.0
       v20.17.0
       v20.18.0
->     v22.14.0
default -> 22.14.0 (-> v22.14.0)
iojs -> N/A (default)
unstable -> N/A (default)
node -> stable (-> v22.14.0) (default)
stable -> 22.14 (-> v22.14.0) (default)
lts/* -> lts/jod (-> v22.14.0)
lts/argon -> v4.9.1 (-> N/A)
lts/boron -> v6.17.1 (-> N/A)
lts/carbon -> v8.17.0 (-> N/A)
lts/dubnium -> v10.24.1 (-> N/A)
lts/erbium -> v12.22.12 (-> N/A)
lts/fermium -> v14.21.3 (-> N/A)
lts/gallium -> v16.20.2 (-> N/A)
lts/hydrogen -> v18.20.7 (-> N/A)
lts/iron -> v20.18.3 (-> N/A)
lts/jod -> v22.14.0

How did you install nvm?

• Homebrew

What steps did you perform?

Background info: Corepack is bundled with all Node.js versions since 14.9.0/16.9.0, but it is supposed to be disabled by default.

I installed Node.js 22.14.0 using the --reinstall-packages-from=default argument:

nvm install 22.14.0  --reinstall-packages-from=default
Downloading and installing node v22.14.0...
Local cache found: ${NVM_DIR}/.cache/bin/node-v22.14.0-darwin-arm64/node-v22.14.0-darwin-arm64.tar.xz
Checksums match! Using existing downloaded archive ${NVM_DIR}/.cache/bin/node-v22.14.0-darwin-arm64/node-v22.14.0-darwin-arm64.tar.xz
Now using node v22.14.0 (npm v10.9.2)
VERSION=''
Reinstalling global packages from v20.17.0...

changed 1 package in 432ms
Linking global packages from v20.17.0...
No linked global packages found...

My previous default was 20.17.0, so it had Corepack bundled, but Corepack was disabled.

What happened?

Node.js 22.14.0 got installed correctly, but it has Corepack enabled unexpectedly. I only noticed because my yarn commands started adding a "packageManager" field to my package.json file, which is an indicator that Corepack is enabled (see nodejs/corepack#485).

I verified that Corepack is enabled by listing the files in my Node.js bin directory:

ls -l /Users/joe/.nvm/versions/node/v22.14.0/bin     
total 212152
lrwxr-xr-x  1 joe  staff         45 Mar 11 13:36 corepack -> ../lib/node_modules/corepack/dist/corepack.js
-rwxr-xr-x  1 joe  staff  108619024 Feb 10 19:45 node
lrwxr-xr-x  1 joe  staff         38 Feb 10 19:45 npm -> ../lib/node_modules/npm/bin/npm-cli.js
lrwxr-xr-x  1 joe  staff         38 Feb 10 19:45 npx -> ../lib/node_modules/npm/bin/npx-cli.js
lrwxr-xr-x  1 joe  staff         41 Mar 11 13:36 pnpm -> ../lib/node_modules/corepack/dist/pnpm.js
lrwxr-xr-x  1 joe  staff         41 Mar 11 13:36 pnpx -> ../lib/node_modules/corepack/dist/pnpx.js
lrwxr-xr-x  1 joe  staff         41 Mar 11 13:36 yarn -> ../lib/node_modules/corepack/dist/yarn.js
lrwxr-xr-x  1 joe  staff         44 Mar 11 13:36 yarnpkg -> ../lib/node_modules/corepack/dist/yarnpkg.js

From what I can tell, the --reinstall-packages-from argument treats Corepack as a globally-installed package (since it's in the global node_modules directory, I presume). When you use nvm to install a new version of Node.js, it installs and enables Corepack (regardless of whether Corepack was enabled or not).

After I used corepack disable to disable Corepack, the symlinks are gone:

ls -l /Users/joe/.nvm/versions/node/v22.14.0/bin
total 212152
lrwxr-xr-x  1 joe  staff         45 Mar 11 13:36 corepack -> ../lib/node_modules/corepack/dist/corepack.js
-rwxr-xr-x  1 joe  staff  108619024 Feb 10 19:45 node
lrwxr-xr-x  1 joe  staff         38 Feb 10 19:45 npm -> ../lib/node_modules/npm/bin/npm-cli.js
lrwxr-xr-x  1 joe  staff         38 Feb 10 19:45 npx -> ../lib/node_modules/npm/bin/npx-cli.js

However, the problem is not just that Corepack is enabled unexpectedly -- it has been reinstalled, overriding the version of Corepack that is supposed to be bundled with this version of Node.js. For example, using the steps listed above, my local installation of Node.js is using Corepack v0.29.3 when it is supposed to be using v0.31.0.

This behavior is an even bigger problem when you try to install an older version of Node.js that is incompatible with the newer version of Corepack.

What did you expect to happen?

1. The --reinstall-packages-from argument should not reinstall Corepack.
2. The --reinstall-packages-from argument should not enable Corepack either.

Is there anything in any of your profile files that modifies the PATH?

.zshrc:

export PATH=$PATH:/opt/homebrew/opt/python@3.9/libexec/bin
export PATH="/opt/homebrew/opt/openjdk/bin:$PATH"

[ljharb]

Do note that nvm is not supported when installed via homebrew; please brew remove it and install it with the install script instead.

---

All nvm does is npm install -g corepack (and whatever else was globally installed). corepack enable isn't something nvm runs, so unless merely installing it enables it, then I'm not sure what we can do here.

Certainly nvm could, like npm itself, omit it from the list of reinstalled packages, but then that would break someone who wants corepack installed globally. Had you previously enabled corepack on v20.17.0?

[jportner]

Do note that nvm is not supported when installed via homebrew; please brew remove it and install it with the install script instead.

TIL, thanks

All nvm does is npm install -g corepack (and whatever else was globally installed). corepack enable isn't something nvm runs, so unless merely installing it enables it, then I'm not sure what we can do here.

Yes I assume that something about the install is what actually enables it, but I wanted to call it out as a separate bullet point.

Certainly nvm could, like npm itself, omit it from the list of reinstalled packages, but then that would break someone who wants corepack installed globally. Had you previously enabled corepack on v20.17.0?

No I haven't enabled Corepack on 20.17.0.
In fact when I was troubleshooting this, I completely removed nvm and all Node.js versions from my system, and re-installed nvm and each Node.js version individually.

Hm, I was under the impression that Corepack is only meant to be bundled with Node.js. However, I checked the Corepack docs and they do mention instructions to install it separately if you wish. I am not aware of any way you could differentiate between a bundled Corepack and a separately-installed Corepack.

IMO, the current negative behavior outweighs the edge case if someone manually installed Corepack.

[ljharb]

hmm - i use --reinstall-packages-from constantly, and it seems that i just don't use repos with packageManager, since i haven't run into this.

i do see that which yarn and which pnpm prints out a path despite them not being in npm ls -g, and corepack disable fixes them. This is definitely something that needs fixing.

[ljharb]

ok, so the issue is that npm install -g corepack always enables it; it only comes disabled with node. so, either i can filter it out of the list, which will break someone who's manually installed it, or i can run corepack disable only when you're installing a new node, which will do the same - but in the latter case, nvm reinstall-packages would cause it to be enabled.

Unfortunately I don't see any easy way to determine if corepack is enabled or not, which would let me match that status from the source node version.

[jportner]

Unfortunately I don't see any easy way to determine if corepack is enabled or not, which would let me match that status from the source node version.

Yeah, I looked into that too. I think you could infer if Corepack is enabled by checking if its symlinks are present, but that seems a little messy.

ok, so the issue is that npm install -g corepack always enables it; it only comes disabled with node. so, either i can filter it out of the list, which will break someone who's manually installed it, or i can run corepack disable only when you're installing a new node, which will do the same - but in the latter case, nvm reinstall-packages would cause it to be enabled.

I think filtering it might be a better idea, because otherwise you risk actually installing an unexpected (potentially incompatible) version of Corepack with Node.js.

Maybe it would be good enough to simply filter and warn the user? Something like "Global installation of Corepack is detected but has been skipped". I don't know how many people realistically have a non-standard version of Corepack installed, but I can imagine this is a very small edge case...

[ljharb]

I agree, I'm just going to filter.

If I get complaints, then I can warn when corepack is being filtered, and/or I can ask the corepack folks to provide a way to solve the problem.