yarn install: Usage, Options & Common CI Errors
Install dependencies from yarn.lock.
yarn install resolves dependencies and writes node_modules (or a PnP store) from package.json and yarn.lock. In CI you want it to fail if the lockfile would change.
What it does
Resolves the dependency graph, fetches packages, links them, and updates yarn.lock if needed. In CI use --immutable (Yarn 2+/Berry) or --frozen-lockfile (Yarn 1) so a stale lockfile fails the build instead of being silently rewritten.
Common usage
yarn install # install everything
yarn install --immutable # Yarn 2+: fail if lockfile changes
yarn install --frozen-lockfile # Yarn 1: same intent (classic)
yarn install --production # Yarn 1: skip devDependenciesCommon CI error: lockfile would change
CI fails with "Your lockfile needs to be updated, but yarn was run with --frozen-lockfile" (Yarn 1) or "YN0028 / The lockfile would have been modified by this install" (Berry). package.json changed without updating yarn.lock. Run yarn install locally and commit the updated yarn.lock; keep CI immutable.
# locally:
yarn install
git add yarn.lock && git commit -m "update lockfile"Key options
| Flag | Effect |
|---|---|
| --immutable | Yarn 2+: error if lockfile/store would change |
| --frozen-lockfile | Yarn 1: error if lockfile would change |
| --production | Yarn 1: skip devDependencies |
| --check-cache | Re-validate cached package integrity |
Using this in CI
Node tooling on a runner differs from your machine in three ways that matter: CI=true is set, there is no TTY, and the Node major may not be the one you develop on.
- Pin the Node major with
setup-nodeand inengines. Native modules resolve different prebuilt binaries per major. CI=truechanges behaviour in several tools, most often by promoting warnings to errors or disabling interactive prompts.- Commands that expect a TTY will hang. Pass the non-interactive or
--yesflag explicitly. - Use
npm execornode_modules/.binrather than assuming a globally installed binary is on PATH.