Error Codes | Yarn

Are you a plugin author and want to declare your own error codes that don't match the semantic of the ones provided here? Please relinquish one character and use the YNX prefix (ex YNX001) instead of YN0!
Keeping this convention will help our users to figure out which error codes can be found on this documentation and which ones should instead be checked against the individual documentation of the plugins they use.
This code is used to log regular messages, mostly to align all the lines in the Yarn output. No worry!
An exception had be thrown by the program.
This error typically should never happen (it should instead point to a different error message from this page so that it can be properly documented), so it should be considered a bug in Yarn. Feel free to open an issue or, even better, a pull request aiming to fix it.
A package requests a peer dependency, but one or more of its parents in the dependency tree doesn't provide it.
Note that Yarn enforces peer dependencies at every level of the dependency tree. That is, if ─D> is a dependency and ─P> is a peer dependency,
Depending on your situation, multiple options are possible:
The author of packageA can fix this problem by adding a peer dependency on packagePeer. If relevant, they can use optional peer dependencies to this effect.
The author of packageB can fix this problem by marking the packagePeer peer dependency as optional - but only if the peer dependency is actually optional, of course!
The author of project can fix this problem by manually overriding the packageA and/or packageB definitions via the packageExtensions config option.
To understand more about this issue, check out this blog post.
Two packages with build scripts have cyclic dependencies.
Cyclic dependencies are a can of worms. They happen when a package A depends on a package B and vice-versa Sometime can arise through a chain of multiple packages - for example when A depends on B, which depends on C, which depends on A.
While cyclic dependencies may work fine in the general Javascript case (and in fact Yarn won't warn you about it in most cases), they can cause issues as soon as build scripts are involved. Indeed, in order to build a package, we first must make sure that its own dependencies have been properly built. How can we do that when two packages reference each other? Since the first one to build cannot be deduced, such patterns will cause the build scripts of every affected package to simply be ignored (and a warning emitted).
There's already good documentation online explaining how to get rid of cyclic dependencies, the simplest one being to extract the shared part of your program into a third package without dependencies. So the first case we described would become A depends on C, B depends on C, C doesn't depend on anything.
A package has build scripts, but they've been disabled across the project.
Build scripts can be disabled on a global basis through the use of the enableScripts settings. When it happens, a warning is still emitted to let you know that the installation might not be complete.
The safest way to downgrade the warning into a notification is to explicitly disable build scripts for the affected packages through the use of the dependenciesMeta[].built key.
A package has build scripts, but they've been disabled through its configuration.
Build scripts can be disabled on a per-project basis through the use of the dependenciesMeta settings from the package.json file. When it happens, a notification is still emitted to let you know that the installation might not be complete.
A package has build scripts, but is linked through a soft link.
For Yarn, a hard link is when a package is owned by the package manager. In these instances Yarn will typically copy packages having build scripts into a project-local cache so that multiple projects with multiple dependency trees don't use the same build artifacts. So what's the problem with so-called "soft links"?
Soft links are when the package manager doesn't own the package source. An example is a workspace, or a dependency referenced through the portal: specifier. In these instances Yarn cannot safely assume that executing build scripts there is the intended behavior, because it would likely involve mutating your project or, even worse, an external location on your disk that might be shared by multiple projects. Since Yarn avoids doing anything unsafe, it cannot run build scripts on soft links.
There are a few workarounds:
Using file: instead of portal: will cause a hard link to be used instead of a soft link. The other side of the coin will be that the packages will be copied into the cache as well, meaning that changing the package source will require you to run YARN_UPDATE_FILE_CACHE=1 yarn install for your changes to be taken into account.
You can manually run yarn run postinstall (or whatever is named your build script) from the directory of the affected packages. This requires you to know in which order they'll have to be called, but is generally the safest option.
You can simply abstain from using build scripts with soft links. While this suggestion might seem like a bad case of "fix a problem by not encountering the problem", consider that build scripts in development might not be of the best effect from a developer experience perspective - they usually mean that you'll need to run a script before being able to see your changes, which is often not what you seek.
A package must be built.
This informational message occurs when Yarn wishes to let you know that a package will need to be built for the installation to complete. This usually occurs in only two cases: either the package never has been built before, or its previous build failed (returned a non-zero exit code).
A package must be rebuilt.
This information message occurs when Yarn wishes to let you know that a package will need to be rebuilt in order for the installation to complete. This usually occurs in a single case: when the package's