Corepack remains when upgrading to Node.js 25.0.0

[MikeMcC399]

Bug Report

Summary

Although Node.js 25.0.0 removed Corepack from Node.js >=25, switching from a Node.js version with bundled Corepack, such as one of the Node.js LTS versions, to Node.js 25.0.0 which does not distribute Corepack, retains the previously installed Corepack version.

Steps to Reproduce

n 20
corepack --version
n 25
corepack --version

Expected Behaviour

Node.js >=25 no longer bundles Corepack with Node.js, so switching to such a version should not preserve the previously installed Corepack version.

The result of switching to Node.js >=25 should also be deterministic. Leaving a previously installed version of Corepack in place means that it is not, because it then depends on what version of Node.js (and therefore what version of Corepack) was previously installed.

Actual Behaviour

Running the steps to reproduce shows Corepack 0.33.0 left over from Node.js 20.19.5 when switching to Node.js 25.0.0

$ n 20
corepack --version
n 25
corepack --version
     copying : node/20.19.5
   installed : v20.19.5 (with npm 10.8.2)
0.33.0
     copying : node/25.0.0
   installed : v25.0.0 (with npm 11.6.2)
0.33.0

Other Information

• The Corepack README documents the removal of Corepack from the Node.js bundle starting with Node.js 25.0.0.

• corepack is not removed when downgrading node #789 already discussed this issue in terms of downgrading. The situation with upgrading to Node.js >=25 is new. Given that Corepack is permanently removed from Node.js 25.0.0, and from future versions of Node.js, I suggest that the issue and strategy needs to be revisited.

Configuration Details

$ n --version
10.2.0

$ command -v node
/home/mike/n/bin/node

$ node -p process.platform
linux

[shadowspawn]

n overwrites previous Node.js installs. There isn't any general support for removing artefacts from previous versions. There are a few specific cases handled, like doing a clean directory copy for npm (#470).

The big gotcha with corepack is that it may have been manually installed, and I don't know how to tell the difference between a manual install and installed as part of Node.js. (I think possible to tell if corepack is currently being actively used by looking to see if yarn or pnpm (or npm) are symbolic links into corepack, which would be a clue to not delete.)

Is there a particular problem that corepack being left behind causes?

[MikeMcC399]

@shadowspawn

The big gotcha with corepack is that it may have been manually installed, and I don't know how to tell the difference between a manual install and installed as part of Node.js. (I think possible to tell if corepack is currently being actively used by looking to see if yarn or pnpm (or npm) are symbolic links into corepack, which would be a clue to not delete.)

My expectation would be that n sets up exactly the versions of npm and corepack that are bundled with the Node.js version selected. If alternate versions have been installed with npm install -g, then I would fully expect these to be overwritten. If corepack isn't bundled then it should be removed.

Perhaps this needs a new option for n to achieve a clean installation when switching between Node.js versions? This would make n work like nvm works. nvm use 25 leaves no Corepack installed whether any previously installed Corepack version was put there out of a Node.js bundle or whether it was manually installed with npm install -g corepack.

Is there a particular problem that corepack being left behind causes?

Corepack intrusively changes the outcome of some npm, yarn and pnpm commands, so if it is installed, when it is not supposed to be, then commands may work differently or fail.

For the moment, I can work around this by manually uninstalling Corepack (npm uninstall -g corepack) after switching to Node.js 25.

[MikeMcC399]

If this isn't considered a bug, and there is no new option to force n to do a clean install of Node.js (without Corepack, if that is what the selected Node.js version defines), then I will migrate to using nvm instead. I'd prefer to stay with n, however at this time it seems that nvm better fits my needs.

[shadowspawn]

If you don't use corepack when you are using a version of Node.js which would otherwise include it, a current workaround might be to tell n to leave alone corepack by default. Once you uninstall it, it won't come back.

export N_PRESERVE_COREPACK=1

Bug? Limitation? Still thinking about it!

[MikeMcC399]

@shadowspawn

Thanks for the hint about setting the environment variable N_PRESERVE_COREPACK=1!

Unfortunately this doesn't fulfil my needs. When I switch back to a Node.js version that has Corepack bundled, it doesn't get installed.

export N_PRESERVE_COREPACK=1
n 25.0.0
npm uninstall corepack -g
corepack -v # correctly shows "No such file or directory"
n 24.10.0
corepack -v # fails
unset N_PRESERVE_COREPACK
n 24.10.0
corepack -v # shows 0.34.0

Possibly my request should be separately handled as an enhancement request to suggest a "strict" installation mode that simply installs Node.js exactly as published on https://nodejs.org/dist/ with no regard for what was previously installed locally, also overriding any N_PRESERVE_* settings?

[shadowspawn]

Deleting corepack when installing node 25 onwards is consistent with not being included in Node.js, but not helpful with using corepack as a global install going forward, which is the future way to use it.

By default, nvm and fnm and other strictly isolated Node.js managers will have no extra global packages available when a Node.js version is first downloaded. n overwrites the install so all the global packages stay available. Different approaches, different trade-offs.

# some version of node installed
npm install -g n
n 25.0.0
npm install -g corepack
corepack enable
n 25.0.1
# both global packages still available
corepack --version
n --version

My current thinking is that is you have not enabled corepack, then just having it installed does not change anything (except for its availability). If you have enabled corepack, then you are using it and retaining it seems probably useful.

I am interested in hearing what people want/need. I have only played with corepack, not used it for real. (Thanks for the issue and comments @MikeMcC399 )

[MikeMcC399]

@shadowspawn

I'm using Corepack selectively enabled and disabled in https://github.com/cypress-io/github-action/blob/master/scripts/update-cypress-latest-yarn.sh to update Yarn v1 Classic (no Corepack) and Yarn Modern (with Corepack) examples for Cypress using GitHub Actions.

I've stopped using Corepack for anything else due to its experimental status and assessment that it will never exit this status ever. The decision by the Node.js TSC, to stop bundling it, has effectively led to a winding down of any further development and many issues remain open. The Yarn lead maintainer, who was a major author of Corepack, has already stated that they intend to provide a replacement for Corepack for use with Yarn (Modern). So in all, I don't think Corepack warrants any major strategy change on the part of n.

I think I'm going to need to rework my scripts so that they are consistent with Node.js >=25, which actually doesn't begin to be an issue until we get to Node.js 26 being released and then moving to LTS in Oct 2026. This probably means I'm going to explicitly install Corepack in my scripts when necessary, and not rely on n functionality.

So, in summary, I'd suggest holding back at the moment and leaving this issue open in case there are other users with related needs related to Corepack.

Many thanks for the discussion!