A tool to manage versioning and changelogs
with a focus on multi-package repositories
The changesets
workflow is designed to help when people are making changes, all the way through to publishing. It lets contributors declare how their changes should be released, then we automate updating package versions, and changelogs, and publishing new versions of packages based on the provided information.
Changesets has a focus on solving these problems for multi-package repositories, and keeps packages that rely on each other within the multi-package repository up-to-date, as well as making it easy to make changes to groups of packages.
A changeset
is an intent to release a set of packages at particular semver bump types with a summary of the changes made.
The @changesets/cli package allows you to write changeset
files as you make changes, then combine any number of changesets into a release, that flattens the bump-types into a single release per package, handles internal dependencies in a multi-package-repository, and updates changelogs, as well as release all updated packages from a mono-repository with one command.
If you just want to jump in to using changesets, the Intro to using changesets and @changesets/cli docs are where you should head.
If you want a detailed explanation of the the concepts behind changesets, or to understand how you would build on top of changesets, check out our detailed-explanation.
We also have a dictionary.
While changesets can be an entirely manual process, we recommend integrating it with how your CI works.
To check that PRs contain a changeset, we recommend using the changeset bot, or if you want to fail builds on a changesets failure, run yarn changeset status
in CI.
To make releasing easier, you can use this changesets github action to automate creating versioning pull requests, and optionally publishing packages.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。