- Getting Set up
- Building Samples and Packages
- Running a Sample or Storybook
- Testing your changes
- Writing unit tests
- Submitting a PR
- Having your changes published
Once you have gotten setup with the repo, made and tested your changes, there are two more small checks before submitting your PR:
- Update any
API
files - Generate required change files
To ensure we do not break any existing public APIs, we use api-extractor across all our npm packages. This generates a file detailing all public exports of the package. You can find this file under package-root/review/package-name.api.md
. We do this to prevent any accidental breaking changes to the packages we export, and to ensure we do not accidentally publish any internal helper classes/functions.
When a package is built the api-extractor is automatically run and will update the corresponding api.md
file.
To ensure these API files have been updated, run rush build -t "package-name
for each package you have made changes to and submit any changed api.md
files along with your PR.
To ensure we have high-quality changelogs when new versions are released, and make sure your contribution does not go unaccredited for, we ask you to create a change file to describe your changes. To generate the change file first make sure all your changes are committed, then run:
rush changelog
This will start an interactive tool that will:
-
First ask you to select whether your change is a Major, Minor, or Patch (for more information on which to choose see: semver docs)
-
Then ask for a short description of your change - this is what will be included in the changelog when a new version is released, so keep it concise and meaningful. See Tips for writing meaningful changelog entries.
It will ask you these questions for each package you have made changes in.
Once that is done, commit these change files and include them in your PR.
You're ready to submit your PR! 🚀 Thank you for your contribution!
Once you have submitted your PR it must pass several automated checks that help keep our packages and repo healthy:
- ✅ At least two reviewers must approve the changes
- ✅ All packages, samples, and storybook must build successfully
- ✅ Unit tests must all pass
- ✅ Linting must succeed without warnings
- ✅ Appropriate change files must be included
- ✅ Check for public API regressions must not fail
- Next: Having your changes published
- Previous: Writing unit tests