Important: This documentation covers Yarn 2. For the 1.x doc, check classic.yarnpkg.com.
Yarn
yarn addyarn binyarn cache cleanyarn config getyarn config setyarn configyarn constraints queryyarn constraints sourceyarn constraintsyarn dlxyarn inityarn installyarn linkyarn nodeyarn npm infoyarn npm loginyarn npm publishyarn npm whoamiyarn packyarn patch-commityarn patchyarn plugin importyarn plugin listyarn plugin runtimeyarn rebuildyarn removeyarn runyarn set resolutionyarn set version from sourcesyarn set versionyarn stageyarn unplugyarn upyarn upgrade-interactiveyarn version applyyarn version checkyarn versionyarn whyyarn workspaceyarn workspaces foreachyarn workspaces list

yarn add

Add dependencies to the project.

Usage

$> yarn add [--json] [-E,--exact] [-T,--tilde] [-C,--caret] [-D,--dev] [-P,--peer] [-O,--optional] [--prefer-dev] [-i,--interactive] [--cached] ...

Examples

Add a regular package to the current workspace :

yarn add lodash

Add a specific version for a package to the current workspace :

yarn add lodash@1.2.3

Add a package from a GitHub repository (the master branch) to the current workspace using a URL :

yarn add lodash@https://github.com/lodash/lodash

Add a package from a GitHub repository (the master branch) to the current workspace using the GitHub protocol :

yarn add lodash@github:lodash/lodash

Add a package from a GitHub repository (the master branch) to the current workspace using the GitHub protocol (shorthand) :

yarn add lodash@lodash/lodash

Add a package from a specific branch of a GitHub repository to the current workspace using the GitHub protocol (shorthand) :

yarn add lodash-es@lodash/lodash#es

Details

This command adds a package to the package.json for the nearest workspace.

  • If it didn't exist before, the package will by default be added to the regular dependencies field, but this behavior can be overriden thanks to the -D,--dev flag (which will cause the dependency to be added to the devDependencies field instead) and the -P,--peer flag (which will do the same but for peerDependencies).

  • If the package was already listed in your dependencies, it will by default be upgraded whether it's part of your dependencies or devDependencies (it won't ever update peerDependencies, though).

  • If set, the --prefer-dev flag will operate as a more flexible -D,--dev in that it will add the package to your devDependencies if it isn't already listed in either dependencies or devDependencies, but it will also happily upgrade your dependencies if that's what you already use (whereas -D,--dev would throw an exception).

  • If set, the -O,--optional flag will add the package to the optionalDependencies field and, in combination with the -P,--peer flag, it will add the package as an optional peer dependency. If the package was already listed in your dependencies, it will be upgraded to optionalDependencies. If the package was already listed in your peerDependencies, in combination with the -P,--peer flag, it will be upgraded to an optional peer dependency: "peerDependenciesMeta": { "<package>": { "optional": true } }

  • If the added package doesn't specify a range at all its latest tag will be resolved and the returned version will be used to generate a new semver range (using the ^ modifier by default unless otherwise configured via the savePrefix configuration, or the ~ modifier if -T,--tilde is specified, or no modifier at all if -E,--exact is specified). Two exceptions to this rule: the first one is that if the package is a workspace then its local version will be used, and the second one is that if you use -P,--peer the default range will be * and won't be resolved at all.

  • If the added package specifies a tag range (such as latest or rc), Yarn will resolve this tag to a semver version and use that in the resulting package.json entry (meaning that yarn add foo@latest will have exactly the same effect as yarn add foo).

If the --cached option is used, Yarn will preferably reuse the highest version already used somewhere within the project, even if through a transitive dependency.

If the -i,--interactive option is used (or if the preferInteractive settings is toggled on) the command will first try to check whether other workspaces in the project use the specified package and, if so, will offer to reuse them.

If the --json flag is set the output will follow a JSON-stream output also known as NDJSON (https://github.com/ndjson/ndjson-spec).

For a compilation of all the supported protocols, please consult the dedicated page from our website: .