ci: stop fetching an unpinned Yarn before the pinned one

[dpage]

Everywhere we build the JS, we asked Yarn to install itself twice:

yarn set version berry
yarn set version <the version from packageManager>

The first call fetches whichever release is "berry" today and the second immediately replaces it, so every build made two downloads to arrive at one Yarn, and the one that could not be reproduced tomorrow was fetched first.

That first fetch broke CI outright today, during the GitHub incident, when it returned an empty body and Yarn 1 died writing it out:

error TypeError [ERR_INVALID_ARG_TYPE]: The "data" argument must be of type
string or an instance of Buffer, TypedArray, or DataView
    at writeFile (node:fs:2373:5)

It took out check-javascript-style and run-javascript-tests on #10299, and killed three separate runs of an unrelated investigation before any test executed.

What changes

The unpinned call goes everywhere it appeared: Make.bat, the macOS and pip package builds, and the four workflows. The packaging scripts keep their pinned yarn set version "${YARN_VERSION}", which still reads packageManager from package.json, so their behaviour is unchanged beyond losing a download. pkg/linux/build-functions.sh needed nothing, having only ever used the pinned form.

The four workflows go further and use Corepack, which reads packageManager itself and provisions exactly that Yarn without writing .yarnrc.yml and .yarn/releases into the repository root, where the JS project is not.

The Dockerfile already ran npm install -g corepack && corepack enable immediately before both set version calls, so both were redundant there and are simply removed.

Testing

docker build --target app-builder succeeds with the change, building the image through yarn install and yarn run bundle to a clean webpack compiled and a tagged image. Since web/yarn.lock is __metadata: version: 10, which Yarn 1 cannot parse, the install succeeding is itself proof that Corepack provisioned Yarn 4 from packageManager with no set version involved.

All four workflows parse as YAML with exactly one corepack enable step each, and the three modified shell scripts pass bash -n.

Worth knowing

Corepack ships with Node.js only up to (but not including) 25.0.0, so once the runners move past that it will need installing explicitly, as the Dockerfile already does.

Only run-javascript-tests.yml pins a Node version (20.x); the other three take the runner default, so corepack enable depends on that default staying below 25. Pinning them explicitly would make it deterministic, but it also changes which Node builds the bundle, so I have left that out of a CI plumbing fix rather than slipping it in.

Dockerfile line 31 still installs Alpine's yarn package alongside npm, which looks redundant now that Corepack provides the shim. I have not touched it here, as it deserves its own verification.

[coderabbitai]

Caution

Review failed

An error occurred during the review process. Please try again later.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}