重要提示: 此中文文档针对的是 Yarn 的最新版本。
有关 1.x 版本的中文文档,请点击进入 classic.yarnpkg.cn。
Yarn
ConstraintsPlug'n'PlayPluginsProtocolsRelease WorkflowWorkspacesZero-Installs离线缓存

Plugins

Edit this page on GitHub

Ever since Yarn was created, our very essence has been about experimenting, evolving, pushing the status quo - rinse and repeat, each time one step further, each time paving the way for our next move.

As you can guess, this philosophy (coupled with the high number of external contributions we receive) requires us to iterate fast in order to accommodate the various experiments that we brew. In a major step forward, Yarn got redesigned in the v2 in order to leverage a new modular API that can be extended through plugins. Nowadays, most of our features are implemented through those plugins - even yarn add and yarn install are preinstalled plugins!

What can plugins do?

  • Plugins can add new resolvers. Resolvers are the components tasked from converting dependency ranges (for example ^1.2.0) into fully-qualified package references (for example npm:1.2.0). By implementing a resolver, you can tell Yarn which versions are valid candidates to a specific range.

  • Plugins can add new fetchers. Fetchers are the components that take the fully-qualified package references we mentioned in the previous step (for example npm:1.2.0) and know how to obtain the data of the package they belong to. Fetchers can work with remote packages (for example the npm registry), but can also find the packages directly from their location on the disk (or any other data source).

  • Plugins can add new linkers. Once all the packages have been located and are ready for installation, Yarn will call the linkers to generate the files needed for the install targets to work properly. As an example, the PnP linker would generate the .pnp.cjs manifest, and a Python linker would instead generate the virtualenv files needed.

  • Plugins can add new commands. Each plugin can ship as many commands as they see fit, which will be injected into our CLI (also making them available through yarn --help). Because the Yarn plugins are dynamically linked with the running Yarn process, they can be very small and guaranteed to share the exact same behavior as your package manager (which wouldn't be the case if you were to reimplement the workspace detection, for example).

  • Plugins can register to some events. Yarn has a concept known as "hooks", where events are periodically triggered during the lifecycle of the package manager. Plugins can register to those hooks in order to add their own logic depending on what the core allows. For example, the afterAllInstalled hook will be called each time the Project#install method ends - typically after each yarn install.

  • Plugins can be integrated with each other. Each plugin has the ability to trigger special actions called hooks, and to register themselves to any defined hook. So for example, you could make a plugin that would execute an action each time a package is added as dependency of one of your workspaces!

How to write plugins?

We have a tutorial for this! Head over to Plugin Tutorial.

Official plugins

yarn plugin import <name>
  • constraints - Adds new commands to Yarn to enforce lint rules across workspaces. See the dedicated page for more information.

  • exec - Adds a new protocol to Yarn (exec:) that dynamically generates arbitrary packages rather than downloading them from a known location. See the plugin page for more information.

  • interactive-tools - Adds various commands providing a more high-level control on your project using graphical terminal interfaces (for example yarn upgrade-interactive).

  • stage - Adds a new command to Yarn (yarn stage) to automatically stage & commit all changes to Yarn-related files in a single line.

  • typescript - Improves the TypeScript experience (for example by automatically adding @types packages as dependencies when needed). See the plugin page for more information.

  • version - Adds a new workflow to Yarn (yarn version) to efficiently manage releases in a monorepository. See the dedicated page for more information.

  • workspace-tools - Adds various commands that make working with workspaces a more pleasing experience (for example yarn workspaces foreach).

Contrib plugins

yarn plugin import <bundle url>

This is just a centralized list of third-party plugins to make discovery easier. No guarantees are made as to plugin quality, compatibility, or lack of malicious code. As with all third-party dependencies, you should review them yourself before including them in your project.

  • plugin-installs by Larry1123 - create minimal yarn installs after removing development dependencies, unrelated workspaces, @types packages, etc

  • yarn.build by Owen Kelly - monorepo tooling that leverages Yarn's dependency graph to run build and test on whats changed in parallel as fast as possible. It also includes a command to bundle them up into deployable apps for Docker, AWS Lambda, or any other server. Each command is also available as an individual plugin.

  • package-yaml by Owen Kelly - per package opt-in to transparently using package.yml instead of package.json

  • licenses by Noah Negin-Ulster - audit direct and indirect dependency licenses to ensure compliance

  • semver-up by Noah Negin-Ulster - configurable yarn up command that preserves semantic version ranges and update groups

  • conditions by Nicolò Ribaudo - allow choosing between different dependency versions via install-time (during development) and publish-time flags

  • az-cli-auth by Fish & Richardson P.C - Uses the az cli to generate auth tokens when using azure devops repos

  • gcp-auth by Andreas Clausen - Uses gcloud to generate access tokens when using Google Artifact Registry repos

  • outdated by Mark Skelton - lists outdated dependencies similar to the Yarn 1.x outdated command

  • engines by Yaroslav Admin - enforces a Node version range specified in the package.json's engines.node field

  • licenses by Marc Hassan - adds yarn licenses commands that are similar to the ones in Yarn v1

  • aws-codeartifact by Marc Hassan - resolves authentication for AWS CodeArtifact NPM registries

  • after-install by Marc Hassan - adds support for an afterInstall hook that runs after every yarn install

  • yaml-manifest by Lyle Underwood - use a package.yml with comments and whitespace that is automatically synchronized with package.json

  • yarn-plugin-envinfo by TheKnarf - yarn plugin so that you can run envinfo in your project. It'll read a project local configuration file so that different projects can ask for different info. Useful for helping new developers when onboarding them into your project.

  • publishconfig by Ali Zeaiter - Allows extending publishConfig to support any property on top of the default ones supported by yarn.

  • http-proxy by Aron Tsang - yarn plugin that loads a default http Proxy Agent based on the HTTP_PROXY or HTTPS_PROXY environmental variable when running lifecycle script such as postinstall. This is useful for allowing postinstall scripts to run in corporate environments where internet access requires an explicit HTTP Connect Proxy.

  • changed by Dcard Holdings Ltd. - List and run a command on changed workspaces and their dependents.

  • docker-build by Dcard Holdings Ltd. - Build a Docker image for a workspace.

  • tsconfig-references by Dcard Holdings Ltd. - Update references in tsconfig.json when adding or removing workspaces.

  • yarn-plugin-version-tools by indooorsman - yarn plugin that is almost same with @yarnpkg/plugin-version but add a --preid option for bumping prerelease version.

  • yarn-plugin-pin-deps by Splitgraph - Pin dependencies to their currently resolved exact version. This plugin will find any dependencies referenced with a semver identifier, and will update package.json to replace that identifier with the exact version of the package currently resolved in the lockfile for that reference.

  • yarn-plugin-scripts by jgttech - Add capability to define customized scripts within the .yarnrc.yml file, similar to package.json, but more robost and similar to something like GitHub Actions. Each script can be invoked by its name, such as yarn scripts <name_of_script>. Each script is an array of one or more commands to execute.

  • yarn-plugin-npm-audit-fix by Sargun Vohra - Attempt to automatically resolve audit advisories reported by yarn npm audit.

  • yarn-scripts-cache by Roman Gischkowski - A Yarn Berry plugin to cache script execution results. Previous build results can be restored, even from a remote cache server. This allows for build result sharing with a team of developers, significantly decreasing build times and eliminating downtime.

If you wrote a plugin yourself, feel free to open a PR to add it at the end of this list!