Install the project dependencies.
Examples of use
Install
the project :Validate a project when using Zero-Installs :
Validate a project when using Zero-Installs (slightly safer if you accept external PRs) :
Options
Description-json Format the output as an
immutable
NDJSON stream Abort with an error exit code if the lock file was to be
modified-immutable-cache
Abort with an error exit code if the cache folder was to be
modified-check-cache
Always reretrieve packages and make sure their checksums are consistent
online builds
Print verbatim the output of the build steps from dependency mode
#0
Change which artifacts are installed Generate
Details
This command configures the project if necessary. The installation is divided into four different steps that each have their own characteristics
:
-
Resolution: First the package manager will resolve its dependencies. The exact way in which one dependency version is privileged over another is not standardized outside of semver’s regular guarantees. If a package does not resolve as expected, verify that all dependencies are correctly declared (also see our website for more information: ).
-
Fetch: We then download all dependencies if necessary, and make sure they are all stored within our cache (check the cacheFolder value in yarn config to see where the cache files are stored).
-
Link: Then we send the information from the dependency tree to the internal plugins responsible for writing them to disk in some way (for example, generating the .pnp.cjs file that you may know).
-
Compilation: Once the dependency tree has been written to disk, the package manager will now be free to run build scripts for all packages that may need it, in a topological order compatible with how they depend on each other. See https://yarnpkg.com/advanced/lifecycle-scripts for details.
Note that running this command is not part of the recommended workflow. Yarn supports zero installations, which means that as long as you store your cache and .pnp.cjs file within your repository, everything will work without installation right after cloning your repository or changing branches.
If the -immutable option is set (the default is true in CI), Yarn will be canceled with an error exit code if the lock file is modified (other paths can be added using the immutablePatterns setting). For backward compatibility, we offer an alias named -frozen-lockfile, but it will be removed in a later version.
If the –
immutable-cache option is set, Yarn will abort with an error exit code if the cache folder were modified (either because files would be added or because they would be deleted).
If the –
check-cache option is set, Yarn will always retrieve the packets and make sure that their checksum matches what \’s 1/ described in the lock file 2/ within the existing cache files (if present). This is recommended as part of your CI workflow if you are both following the Zero-Installs model and accepting third-party PR, as otherwise you would have the ability to alter registered packages before sending them.
If the –
inline-builds option is set, Yarn will print verbatim the output of the build steps of its dependencies (instead of writing them to individual files). This is likely to be useful primarily for debugging purposes only when using Docker-like environments.
If the -mode=<mode> option is set, Yarn will change the artifacts that are generated. The currently supported modes are:
-
skip-build will not run build scripts at all. Note that this is different from setting enableScripts to false because the latter will disable build scripts and thus affect the contents of artifacts generated on disk, while the former will only disable the build step, but not the scripts themselves, which simply won’t run.
-
update-lockfile will skip the binding step altogether and only look for packages that are missing from the lock file (or that do not have checksums associated with them). This mode is typically used by tools such as Renovate or Dependabot to keep an up-to-date lock file without incurring the total installation cost.
