What is this Corepack thing anyway?

Currently I use yarn 1.22.22 - a rather dead old version of Yarn. It was discontinued in 2023 (ish), but from what I can tell it’s still widely used by a lot of the FE community. However, since Node 24 I’ve started to get this depreciation warning:

[DEP0169] DeprecationWarning: `url.parse()` behavior is not standardized and prone to errors that have security implications. Use the WHATWG URL API instead. CVEs are not issued for `url.parse()` vulnerabilities.

So, this got me thinking about possible replacements to Yarn. Initially, I looked at PNPM (which I think is the forerunner, but this blog isn’t about PNPM) as a replacement, but i kept seeing references to Corepack no matter what package manager I looked at. Which got me thinking:

What is Corepack? And why is it everywhere?

After reading through the documentation, I found myself rather confused. But, after battling through and messing around, I feel like I have a good handle on it. So this post is for those of you who are also lost and confused with Corepack. I hope these words will help.

So what is Corepack?

Let’s cut to the core (pun intended) of this. On it’s GitHub repo, it states:

In practical terms, Corepack lets you use Yarn, npm, and pnpm without having to install them.

Which confused the crap out of me. Are there generic Corepack commands that wrap generic install commands? Does it install things for you? I’ve always installed package managers. Or my project has come with scripts and binaries to run (e.g. gradle + gradle wrapper).

But the crux of it is; you place

{
"packageManager": <your manager>
}

at the bottom of your package.json, and Corepack will install it and make it available for you to use automatically. No need to download and install specific versions of package managers. They just appear available.

Which, to be fair to the above description from the Github, it does state.

Essentially, all it does is make sure you’re always using the same package manager and a specific version for a project. As it’s defined as part of the package.json, every person who downloads your project (and uses Corepack) will get the defined package manager. That’s pretty great, and should solve some weird build time bugs.

Where does (some) of the confusion come from?

Now we know what Corepack actually does, why is it confusing?

Well, for starters it doesn’t replace your package manager. You still define what package manager your project uses, and use the manager specific commands like yarn start etc.

Next, it’s still technically experimental. Which for any developer signals “here be dragons”, and puts you off using it for production use*. However, it’s been bundled with NodeJS since version 14 which was released 5 years ago. And has lived with the project’s documentation since. How can something be experimental for that long, but also suggested to use by the major package managers? Huh?

However, since NodeJS version 25, it won’t be bundled. So you’ll need to download and install Corepack yourself. That’s… more confusing? Is it still experimantal? I don’t know. But the GitHub project doesn’t suggest it is and it’s ready for prime time.

Ultimately if you do want to use it you still have to call corepack enable. It’s not enabled by default. And if you also have to install too… It’s a bit of a confusing mess.

Wrap up

I think ultimately I like what Corepack is trying to do. Having projects define the version of package managers to use and then automatically download them is rather neat. It should solve weird bugs where one team member or CI server is using a different one to you. That’s a real problem and it’s nice it’s been solved within the NodeJS ecosystem.

However the “marketing” around it, from the perspective of someone who’s not super deep into the world of JavaScript package management, is overly complex and seems rather confusing. It’s been almost 6 years of Corepack, and yet it still seems like an oddity or an added extra. I wonder it no longer being bundled with NodeJS will help? Maybe it’ll be able to fly as it’s own thing. I guess we’ll find out.

*As with all things in development, this isn’t a hard or fast rule. If you have a fully operational Platforms team that are happy to maintain cutting edge tech, then go for it! But for small shops, or one-man-bands, I’d personally recommend avoiding “dragons”.