2 months ago
We are completely unable to build any of our NodeJS services as the yarn-invoked build command fails, related to Corepack. This is affecting even services whose code did not change, as well as rolling back services to branches that previously worked.
Specifically, Railway prints this:
```
Packages
──────────
node │ 24.14.0 │ package.json > engines > node (>=24.0.0)
yarn │ 4.13.0 │ package.json > packageManager (4.13.0)
Steps
──────────
▸ install
$ npm i -g corepack@latest && corepack enable && corepack prepare --activate
$ yarn install --check-cache
▸ build
$ yarn [...]
```
And in the logs I see:
```
npm i -g corepack@latest && corepack enable && corepack prepare --activate
2s
Preparing yarn@4.13.0 for immediate activation...
```
So Railway is successfully detecting our Yarn version and "activating it", but when our custom build command runs:
```
yarn [...]
error This project's package.json defines "packageManager": "yarn@4.13.0". However the current global version of Yarn is 1.22.22.
Presence of the "packageManager" field indicates that the project is meant to be used with Corepack, a tool included by default with all official Node.js distributions starting from 16.9 and 14.19.
Corepack must currently be enabled by running corepack enable in your terminal. For more information, check out https://yarnpkg.com/corepack.
```
I've tried adding the relevant corepack commands to the custom build command, but the same result. We cannot replicate this error by running the service's code locally, even with the same environment variables; this only occurs on Railway.
3 Replies
2 months ago
This usually happens when the build environment ends up using the global Yarn 1 binary instead of the Corepack-managed Yarn version, even though Corepack successfully prepares the correct version earlier in the build.
In Railway builds, the step
npm i -g corepack@latest && corepack enable && corepack prepare --activatecorrectly downloads yarn@4.13.0, but later build commands may still resolve yarn from the globally installed Yarn 1 (1.22.22) that exists in the base image. When that happens, Yarn detects the packageManager field:
"packageManager": "yarn@4.13.0"and throws the error because Yarn 1 cannot run projects configured for Yarn 4.
A reliable workaround is to explicitly activate the correct Yarn version in the same build step where it is used, ensuring the binary path is updated before the build command runs.
Example:
corepack enable
corepack prepare yarn@4.13.0 --activate
yarn --version
yarn install --check-cache
yarn buildAnother approach that avoids the global binary conflict is to invoke Yarn directly through Corepack:
corepack yarn install --check-cache
corepack yarn buildThis guarantees the Corepack-managed Yarn version is used rather than the system Yarn 1 binary.
Also verify that:
package.jsoncontains
"packageManager": "yarn@4.13.0" - the Node version in the environment supports Corepack (Node ≥16.9, which Node 24 already does)
In short, the issue occurs because the build environment resolves Yarn 1 from the global PATH instead of the Corepack-activated Yarn 4 binary, and explicitly invoking or activating Yarn through Corepack in the same step prevents the mismatch.
2 months ago
Update: we found a workaround to commit a specific yarn release to our repo (i.e. .yarn/releases/yarn-4.13.0.cjs) and update the .yarnrc.yml to use it:
yarnPath: .yarn/releases/yarn-4.13.0.cjsWould still like a proper solution, though, as this creates its own problems.
This usually happens when the build environment ends up using the **global Yarn 1 binary instead of the Corepack-managed Yarn version**, even though Corepack successfully prepares the correct version earlier in the build. In Railway builds, the step ``` npm i -g corepack@latest && corepack enable && corepack prepare --activate ``` correctly downloads `yarn@4.13.0`, but later build commands may still resolve `yarn` from the globally installed Yarn 1 (`1.22.22`) that exists in the base image. When that happens, Yarn detects the `packageManager` field: ``` "packageManager": "yarn@4.13.0" ``` and throws the error because Yarn 1 cannot run projects configured for Yarn 4. A reliable workaround is to explicitly activate the correct Yarn version **in the same build step where it is used**, ensuring the binary path is updated before the build command runs. Example: ``` corepack enable corepack prepare yarn@4.13.0 --activate yarn --version yarn install --check-cache yarn build ``` Another approach that avoids the global binary conflict is to invoke Yarn directly through Corepack: ``` corepack yarn install --check-cache corepack yarn build ``` This guarantees the Corepack-managed Yarn version is used rather than the system Yarn 1 binary. Also verify that: * `package.json` contains ``` "packageManager": "yarn@4.13.0" ``` * the Node version in the environment supports Corepack (Node ≥16.9, which Node 24 already does) In short, the issue occurs because the build environment resolves **Yarn 1 from the global PATH instead of the Corepack-activated Yarn 4 binary**, and explicitly invoking or activating Yarn through Corepack in the same step prevents the mismatch.
2 months ago
While I'm also thinking it's some environment variable issue, we tried this trick (in a few different flavors) but did not work. It's as if the yarn binary itself is somehow corrupt.
This has also never been an issue before the tail end of last week, despite not having changed the build process in months.