docker-node
docker-node copied to clipboard
nodejs
feat: enable Corepack (pnpm support, unbundle yarn)
Description
This patch enables Corepack, allowing to use pnpm directly and unbundling yarn from the default image.
Removing yarn also simplifies the image and the maintenance.
Motivation and Context
This change has been discussed in https://github.com/nodejs/docker-node/issues/777.
Closes #777, #1645, #1755.
Testing Details
I build some images generated from the template (I'm using Mac OS X), and tested that Corepack is enabled, yarn unbundled, and pnpm, yarn and npm usable out of the box.
Example Output(if appropriate)
$ docker run -it node sh
# pnpm --version
7.11.0
# yarn --version
1.22.19
# npm --version
8.18.0
Types of changes
- [x] Documentation
- [ ] Version change (Update, remove or add more Node.js versions)
- [ ] Variant change (Update, remove or add more variants, or versions of variants)
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
- [ ] Others (non of above)
To reduce the image size, I decided to not bundle yarn anymore. So there is a potential tiny breaking change: the network is used the first time yarn is used. It wasn't the case previously.
I documented how to prevent this network access (for both yarn and pnpm).
Checklist
- [x] My code follows the code style of this project.
- [x] My change requires a change to the documentation.
- [x] I have updated the documentation accordingly.
- [x] I have read the CONTRIBUTING.md document.
- [x] All new and existing tests passed.
The CI failure is unrelated, it looks like the website generating the badge for the README is down.
Exciting!
I don't however think we can do this for existing images - it'd be a very breaking change. However, we can probably do this for v19 when it comes out next month and for all future versions?
/cc @nodejs/docker
@SimenB looks legit. Let me know when you'll want me to update the PR!
Alternatively, we could run corepack prepare in current images to prevent the backward compatibility break and remove it in v19?
Do you have a preference on how to proceed? Should I keep the old templates and add new ones for future major releases or should I use the same templates and introduce conditions inside the template (sed will probably not be enough then)?
Why would we want it enabled by default in docker if it's not enabled by default in node itself? Shouldn't those two happen at the same time, or not at all?
Why would we want it enabled by default in docker if it's not enabled by default in node itself? Shouldn't those two happen at the same time, or not at all?
I disagree, I don't think those two distributions have the same requirements.
The general Node.js distributions are tarballs that users manipulate in many different and unpredictable ways, whereas the Docker images are fixed environments generally pinned by major version. Enabling Corepack in the Docker images first would be lower risk than enabling it by default in both Docker images and the general distribution, and would provide useful early signals.
Perhaps, but it seems like the TSC should have consensus on eventually enabling corepack by default in node itself - otherwise, enabling it by default anywhere isn't useful, because no signals are needed.
Does it have that consensus?
It's worth double-checking when the time comes to enable it by default on all distributions, but I believe so; opt-in was suggested to derisk the project (https://github.com/nodejs/node/pull/35398#issuecomment-700780197, https://github.com/nodejs/node/pull/35398#issuecomment-700791438), but the point was always to eventually make it the default once we had enough signals that it was working appropriately.
That said, in the specific case of the Node.js Docker images, since Yarn is already distributed there, enabling Corepack would mostly be an implementation change (as long as the default Yarn binary is also made available without requiring the network). In that regards, for the Docker images only, it seems more up to the Release maintainers than the TSC - although I'm not part of either group, so that's just my understanding.
it seems like the TSC should have consensus on eventually enabling corepack by default in node itself
FWIW changes in node are not up to the TSC but to Collaborators, who are the collective owners of the project. The TSC would be involved only if tentatives to reach consensus among collaborators have failed.
Running corepack enable and installing yarn should be equivalent to what we have today, right? Except for pnpm command becoming available. Seems like an improvement on the current situation, plus corepack should get more usage in the wild (although user probably don't know it).
Could that be considered breaking in any way (discussions about pre-installing yarn/pnpm aside)?
EDIT: we could even start with just corepack enable yarn, that should be pretty invisible to end users (except missing env var for yarn version)
We should wait for whatever the resolution in https://github.com/nodejs/node/issues/51931 and https://github.com/nodejs/node/pull/51886 is
https://github.com/nodejs/TSC/issues/1518