enable corepack by default

[hardfist]

What is the problem this feature will solve?

we try to use corepack and "packageManager" to force developers use the same pnpm version, but developers always forget to enable corepack(because it's turned off by default and when we switch node version it's turned off again) which makes packageManager not working at all

What is the feature you are proposing to solve the problem?

enable corepack by default if package.json contains "packageManager".

What alternatives have you considered?

we currently use "engine.pnpm" field to check whether developers use same pnpm version but engine field is annoying when we deals with tons of projects with different version

[aduh95]

I don't think we can enable Corepack depending on the project, either Corepack pnpm executable is on the PATH, or it's not – so I guess your actual request is "can we enable Corepack by default?".

What I would like to see added to Corepack would be some kind of integrity mecanism so Corepack can safely download newer versions of package managers from the internet (currently, it only relies on HTTPS, which is OK but not great for our use case). This is tracked at nodejs/corepack#10. There has been little to no progress on that issue because it requires coordinate work between Corepack maintainers and package manager maintainers. If we're OK moving forward without it, I don't think there's any blocker for enabling Corepack by default.

Before Corepack is enabled by default, we would need to get consensus on the following:

• Would npm be provided through Corepack moving forward? One of the reasons that Corepack got integrated to the project was so we could uncouple Node.js releases and npm releases, so it's definitly a goal to eventually do that. Is now a good time? I guess that's a judgement call.
• What if more package managers are added to Corepack, would they be enabled by default? E.g.: there's an open PR to add Bun to Corepack: [WIP] Add support for bun corepack#307. (EDIT: no)

/cc @nodejs/corepack @nodejs/tsc

[MylesBorins]

Would npm be provided through Corepack moving forward? The reason that Corepack got integrated to the project was so we could uncouple Node.js releases and npm releases, so it's definitly a goal to eventually do that. Is now a good time? I guess that's a judgement call.

I want to call out that the npm team is still not in support of this. It is not how we want npm to be distributed. We can discuss this more at length if needed, but wanted to call this out.

[anonrig]

I want to call out that the npm team is still not in support of this. It is not how we want npm to be distributed. We can discuss this more at length if needed, but wanted to call this out.

Why does npm not want this?

[anonrig]

Adding tsc-agenda to understand where we are with corepack and progress on it.

[MylesBorins]

TL;DR I support unflagging corepack and any package manager that wants to integrate. npm does not wish to integrate for a variety of reasons and we don't want to be forced into supporting this pattern.

I wouldn't block any work to enable corepack by default in Node.js for other package managers, but I do object to it being used for npm, and for any sort of npm support being on by default. My request would be that if corepack is enabled by default that npm support remain behind an additional flag or command that would be opt-in for developers. If developers want a flow that includes corepack I personally think they should choose a different package manager developed and designed to use this pattern such as yarn. This is the beauty of having an ecosystem of tools, and I don't think that npm should be forced to use a pattern it is not designed to utilize.

For the default npm use case I view using corepack to be a regression in a variety of ways. This could be improved over time but would require investment from the npm team that we are not willing to make as we have other priorities we need to focus on.

A couple of the issues I have with corepack when it comes to npm include:

• The jumper pattern

The introduces extra indirection / lack of clarity as to what version of the package manager is being used and where on disk it is if you need to debug or review source. It also introduces extra potential error cases / edge cases as you are consuming a package manager in a way it was not designed to be used. Perhaps for yarn, which is being developed with corepack in mind, this is fine... but for npm it is being designed / developed with the assumption that it lives on disk in a certain location.

This introduces an extra support burden to our team when things don't work as expected and also introduces new "heisenbugs". My preference is that we explicitly don't support this pattern nor enable it by default and by association explicitly don't support problems developers would have with it.

• pinning the package manager at a project level can lead to exposure to security vulnerability

While it is true that we pin the package manager within a version of Node.js, we do security updates to Node.js when the embedded version of npm is known to have security vulnerabilities. We extensively test to ensure there are no regressions and publish updates. With the pattern of corepack projects that opt to lock to a specific version of the package manager do not get updates even if the version in Node.js, or the default version in Corepack, updates. This is not too different from how a package-lock works, but there exists no ecosystem tooling today to warn developers when their pinned package manager is vulnerable (e.g. dependabot). This is imho a regression in security posture. We do significant work to guarantee consistency with npm moving forward and in general want people on the latest version ASAP, pinning the package manager in the project is an anti-pattern in this scenario.

• Lack of clear testing of node + package manager version to update package manager versions

Currently with the embedded version of npm there are a variety of tests, including CITGM, which test the version of npm that ships with Node.js. Corepack decouples this by updating the package managers internally and then updating the version of corepack in Node.js. We can develop process around this to ensure that it is as robust as what we do today, but to the best of my knowledge this hasn't been done yet.

• A hard coded version for package managers in Corepack adding additional labor to updating

First off, I recognize this is a bit of double speak... I point out the challenge in inconsistent versioning while also claiming pinned versions to be a problem. As a meta point I think this is part of the problem with Corepack for npm, it introduces a bunch of complexity and inconsistency w/o significantly improving the status quo.

Currently core pack has npm 10.2.3 hard coded in it's config. This arguably undermines one of the biggest benefits that was originally claimed for corepack when it shipped, which was that the updating of package managers would be decouple from core. This adds an extra step where we need to update the package managers independently in corepack and then update corepack in Node.js. This is an additional step and additional work for our team and the Node.js team to maintain. This also couple the update of a package manager, with the update of other package managers and corepack itself. The most recent update PR has been open for over a month without review.

• Must dynamically install the package manager over the network to get started

If we were to "unship" Node.js and only ship Corepack we would require dynamically fetching npm over the network in order to get started. Any project that has a pinned version of npm w/o that version being cached also needs to fetch something over the network to get started. Not only does this create additional friction in developer workflow it introduces an extra place for a MITM attack in which the package manager could be replaced with something compromised.

• Lack of clear benefit to npm while creating additional work

In summary I see a whole bunch of additional complexity to using npm, to maintaining npm in core, and additional work for the npm to support corepack without significant benefit to the overall npm experience. Arguably it offers a worse experience for npm developers based on the way in which the npm team has designed npm to work. Once again I want to call out that if other package managers are designing and developing their package managers to deeply integrate and work with corepack, that's awesome! For npm this does not align with our design philosphy and enabling it by default would be going against the wishes of the team.

[aduh95]

Currently core pack has npm 10.2.3 hard coded in it's config. This arguably undermines one of the biggest benefits that was originally claimed for corepack when it shipped, which was that the updating of package managers would be decouple from core.

One that point, since nodejs/corepack#134 has landed, the pinned version hardly matters (it's only used if COREPACK_DEFAULT_TO_LATEST env variable is set to 0).

[trivikr]

There are multiple data points from the community in nodejs/corepack#104 to make corepack stable.

[MylesBorins]

I was doing some searching to see about the use of corepack and npm and came across this on twitter from just 10 days ago

I'm not trying to say that this couldn't be fixed, but it is an example of a support edge case the npm team does not want to have to manage.

[merceyz]

I'm not trying to say that this couldn't be fixed

That should be fixed already; nodejs/corepack#276.