Important: This documentation covers Yarn 2. For 1.x docs, see
yarn addyarn binyarn cache cleanyarn config getyarn config setyarn configyarn dlxyarn execyarn inityarn installyarn linkyarn nodeyarn npm infoyarn npm loginyarn npm logoutyarn npm publishyarn npm whoamiyarn packyarn patch-commityarn patchyarn plugin import from sourcesyarn plugin importyarn plugin listyarn plugin removeyarn plugin runtimeyarn rebuildyarn removeyarn runyarn searchyarn set resolutionyarn set version from sourcesyarn set versionyarn stageyarn unplugyarn upyarn upgrade-interactiveyarn version applyyarn version checkyarn versionyarn whyyarn workspaceyarn workspaces focusyarn workspaces foreachyarn workspaces list

yarn install

Install the project dependencies.


$> yarn install [--json] [--immutable] [--immutable-cache] [--check-cache] [--inline-builds]


Install the project :

yarn install

Validate a project when using Zero-Installs :

yarn install --immutable --immutable-cache

Validate a project when using Zero-Installs (slightly safer if you accept external PRs) :

yarn install --immutable --immutable-cache --check-cache


This command setup your project if needed. The installation is splitted in four different steps that each have their own characteristics:

  • Resolution: First the package manager will resolve your dependencies. The exact way a dependency version is privileged over another isn't standardized outside of the regular semver guarantees. If a package doesn't resolve to what you would expect, check that all dependencies are correctly declared (also check our website for more information: ).

  • Fetch: Then we download all the dependencies if needed, and make sure that they're all stored within our cache (check the value of cacheFolder in yarn config to see where are stored the cache files).

  • Link: Then we send the dependency tree information to internal plugins tasked from writing them on the disk in some form (for example by generating the .pnp.js file you might know).

  • Build: Once the dependency tree has been written on the disk, the package manager will now be free to run the build scripts for all packages that might need it, in a topological order compatible with the way they depend on one another.

Note that running this command is not part of the recommended workflow. Yarn supports zero-installs, which means that as long as you store your cache and your .pnp.js file inside your repository, everything will work without requiring any install right after cloning your repository or switching branches.

If the --immutable option is set, Yarn will abort with an error exit code if anything in the install artifacts (yarn.lock, .pnp.js, ...) was to be modified. For backward compatibility we offer an alias under the name of --frozen-lockfile, but it will be removed in a later release.

If the --immutable-cache option is set, Yarn will abort with an error exit code if the cache folder was to be modified (either because files would be added, or because they'd be removed).

If the --check-cache option is set, Yarn will always refetch the packages and will ensure that their checksum matches what's 1/ described in the lockfile 2/ inside the existing cache files (if present). This is recommended as part of your CI workflow if you're both following the Zero-Installs model and accepting PRs from third-parties, as they'd otherwise have the ability to alter the checked-in packages before submitting them.

If the --inline-builds option is set, Yarn will verbosely print the output of the build steps of your dependencies (instead of writing them into individual files). This is likely useful mostly for debug purposes only when using Docker-like environments.

If the --json flag is set the output will follow a JSON-stream output also known as NDJSON (