enable corepack by default

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

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

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.

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?

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

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.

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).

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

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.

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

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

My 2 cents is that corepack simplify the life of most developers that prefer to use yarn or pnpm.

I also think there is value in shipping the reference implementation within Node.js (npm).

Last but not least, most devs do not specify their packageManager field, making reproducible build harder when used in Dockerfiles and build steps. This poses a long term danger, mostly because in a few years the newer versions might not be compatible anymore.

me vote for having npm not bundled, but here's another perspective:
modern langs ships with entire toolchains:

rust: rust is installed with rustup, rustup installs cargo (package manager, which is also responsible for orchestrating a build)
python: ships with ensurepip package, which is an offline package that bundles pip in it
dotnet: single command that includes package management and build
go: the go command itself includes build, get, install etc. like dotnet
many others...

I find myself rarely used the npm package manager, instead for something like building minimal images. But though I vote for having corepack managing npm for it's cleaness, there're a perspective where many modern languages maybe, yes, violates the unix philosophy, yet still they're there... and having npm not bundled would break things that assumes that npm is shiped with node

For anyone visiting this issue, the status as of 2024-04-26 is an Open TSC Vote tracked at nodejs/TSC#1527

Instead of removing npm/npx, which I think would be a disservice,
why not add pnpm to the (growing?) npm+yarn collection?

oops nm. came here from a link in a pnpm discussion...

That's not the point of this discussion, and regardless, corepark already supports pnpm

@MylesBorins

I landed here after fighting package-lock.json issues all day. There were two things causing issues. Bugs in npm and not all our developers using the same version of npm.

Both these issues and more could be avoided by npm respecting packageManager I'm not sure what @MylesBorins is defining as npm "supporting" or "using" corepack. But it not respecting the packageManager field is a major pain.

It does not feel in good spirits to expand the scope of this discussion to a much larger and tougher decision regarding unbundling npm, and with the npm team (and myself) having expressed on multiple occasions that we have issues with the technical decisions of corepack and do not want to be forced to support it, it is dissapointing that it feels we are being forced into making a decision here.

I think it'd be a major step forward if corepack was enabled by default and npm would fail to run if I have another PM defined in packageManager. No, I don't think "engines" is a good alternative. It requires me to explicitly tell it to use an outdated version of npm. This is confusing and misleading to anyone happening across the error. packageManager solves this by giving a clear error that you on the wrong PM or version of a PM.

If I'm using npm engines works well enough for npm, but also has the issue of yarn or pnpm not stopping them selves unless explicitly blocked with a non-existent version configured in engines.

If npm at least would fail to run when not specified in packageManager, then bundling of npm would be much less of an issue. Users defaulting to the installed npm would get errors instead of submitting PRs with added package-lock.json files when the project users yarn or pnpm. To me the biggest benefit of corepack is creating a common language all package mangers can use to decide whether they should be used on this project, and enforce that. The installation/delivery is a great benefit but not required.

UPDATE: just realized engines-strict also is required for engines config to be respected by npm this seems like a dual use of the engines field. 1. to restrict the use of npm. 2. to restrict the installation of packages not explicitly supported. While the --force flag is an option it means if I want 1 but not 2 this is not a solution. using packageManager for PMs and engines for package installation seems like a great solution that correctly separates concerns.

Thanks for reading!

P.S Maybe @MylesBorins or someone else can clarify the relationship between npm and node? I get it's the default (I'm not new to the ecosystem), but is npm not owned by a for-profit company? Microsoft>GitHub>NPM? While I understand the npm team have legitimate technical concerns; its hard not to read the objections as a for-profit company wining about supporting the technical needs of an open-source community that is asking it to comply with the new norm and potentially give up marketshare and profits in the process.

@moonmeister

I think it'd be a major step forward if corepack was enabled by default and npm would fail to run if I have another PM defined in packageManager. No, I don't think "engines" is a good alternative. It requires me to explicitly tell it to use an outdated version of npm. This is confusing and misleading to anyone happening across the error. packageManager solves this by giving a clear error that you on the wrong PM or version of a PM.

@moonmeister I'm sorry about your troubles with npm. I share the same sentiment: npm is terrible and we should have better alternatives on a fair playing field.

As to your specific challenge: it can be enforced today, using the engines field along with an .npmrc file in the project. Here's how: https://x.com/elektronik2k5/status/1223240189016858624

I wish we had a hacks free and portable solution which all package managers support.

Hey, this is an issue for the enabling of Corepack. Please direct npm specific concerns to their repo, as these comments are off-topic.

Fwiw I am no longer employed by GitHub, nor do I work for npm.

I continue to believe that npm should remain bundled. I similarly believe that yarn + pnpm should be directly bundled rather than supporting via corepack

I continue to believe that the npm team should not be forced to support corepack. This isn't about corporations whining about support, which is a fairly pessimistic view point, but rather architectural decisions that are not aligned with the project.

I have objected to the use of the jumper pattern from the initial release of corepack and abstained from any voting around the project and significantly restrained my criticism to avoid the appearance of impropriety.

Now that I am without conflict of interest, and no longer a maintainer of node, let me reiterate my stance

I think corepack is net negative for the ecosystem for a number of reasons:

The jumper pattern
Fetching resources from cloud storage maintained by individuals
Introducing additional dynamic fetches of resources for both local + CI/CD pipelines

But I also think that it should be the decision of the maintainers of the various package managers to decide what their official installation process looks like. If yarn + pmpm want to make those decisions, it's up to them. It really doesn't matter if I disagree. BUT, I think it would be a significant overstep to force npm to adopt these behaviors for the same reason.

Falling back on "corporations bad" is super dehumanizing to the large group of people who care big time about the community and the software they deliver. Questioning their integrity because you disagree with their technical decisions is super gross.

@MylesBorins

As the current PM of npm I'd like to reiterate the reiteration from @MylesBorins (recursive ftw).

I believe this issue was already settled, and there isn't much I can add, nothing that sounds as new.

I'm welcome the idea to expand node being bundled with more cli, I believe that resolves most of the paint points here. I hope the resolution is not attached to just one solution and better options can be explored.

Hi folks, I've been following this issue (and other conversations) for a long time and would like to share my summary.

I think devEngines proposal is what community should look forward to, as that's the closest one which received inputs from multiple folks and was under design discussion for a long time.

Whether (and how) to migrate off corepack is your choice. I still love using yarn modern with corepack, and will mostly continue using corepack by downloading from npm even if it's disabled/removed from Node.js - as long as it's maintained. Having said that, I've switched to using npm@10.9.0 with Node.js 22.x on newer smaller projects, as it has implemented devEngines proposal in npm/cli#7766

If you're using pnpm, there's also a manage-package-manager-versions setting introduced in pnpm@9.7.0.

Here are some issues if you want to follow:

corepack to support devEngines Implement devEngines proposal from Package Metadata Interoperability Collab Space corepack#567.
yarn modern package manager to provide an alternative to corepack [Feature] Alternative to Node.js experimental corepack to manage package manager version yarnpkg/berry#6443
pnpm to support devEngines Support devEngines field pnpm/pnpm#8153

Do check which option works best for you. It'll depend on how your project is set up and the urgency in improving tooling.
If you currently use corepack, it's better to wait for Node.js to take a decision before adopting any specific alternative. But only you would know what's best for your project and it's maintainers, and when (and if) to make a change.

devEngines is just a more configurable packageManager field. We still need corepack enabled to actually download and run the right package manager.

In just public GitHub there 68k code mentions of corepack enable
https://github.com/search?q=corepack+enable&type=code

Corepack is incredible improvement for both reproducible builds and developer experience. Can somebody clarify what is blocking corepack from being enabled by default?

It also looks like there is already work underway to remove corepack
#51981

It seems that making decision to remove corepack do not require TSC vote. Just two people having conversation on unrelated issue.

Closing this issue as "not planned" as the Node.js TSC voted to stop distributing corepack in Node.js v25+

Corepack is not going away, and it will still be available on npm.
You can still continue to use corepack by replacing the command corepack enable to npm i -g corepack.

If you're a corepack user and want to contribute to its development, please refer nodejs/corepack#681

Navigation Menu

Repository navigation

enable corepack by default #50963

What is the problem this feature will solve?

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

What alternatives have you considered?

114 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

enable corepack by default #50963

Description

What is the problem this feature will solve?

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

What alternatives have you considered?

Activity

aduh95 commented on Nov 30, 2023

MylesBorins commented on Nov 30, 2023

anonrig commented on Nov 30, 2023

anonrig commented on Dec 19, 2023

MylesBorins commented on Dec 19, 2023

aduh95 commented on Dec 19, 2023

trivikr commented on Dec 20, 2023

MylesBorins commented on Dec 20, 2023

merceyz commented on Dec 20, 2023

mcollina commented on Dec 24, 2023

114 remaining items

frankli0324 commented on Apr 26, 2024

trivikr commented on Apr 26, 2024

joebowbeer commented on Oct 23, 2024

avivkeller commented on Oct 23, 2024

moonmeister commented on Nov 13, 2024

elektronik2k5 commented on Nov 14, 2024

avivkeller commented on Nov 14, 2024

MylesBorins commented on Nov 15, 2024

leobalter commented on Nov 15, 2024

trivikr commented on Nov 15, 2024

chyzwar commented on Nov 28, 2024

chyzwar commented on Nov 28, 2024

trivikr commented on Mar 23, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions