This project uses pnpm.
To get started, run:
corepack enableThen, run:
pnpm iBefore creating a pull request, please raise an issue.
After an issue is created, we generally wait 2-4 weeks before implementing any changes. This provides ample time for engineers to share feedback on proposed changes.
The default branch for this repository is canary. Each relevant commit into
canary triggers a pre-release. Merging canary into main will trigger a
release.
We try to group changes together, when possible, as monthly milestones.
This results in less major version changes than if every commit was merged to
main directly.
This repository uses Standard Release to automate releases - included versioning and release note generation.
Commit standards are based on @commitlint/config-conventional.
Commit messages should be in the format:
type(scope?): message
Resolves #1
The scope should be included most of the time, and all allowed types and scopes are documented here:
By default, commits with the feat type will cause a minor version bump, and
commits with the fix or perf type will cause a patch version bump.
If your commit is a breaking change, which will create new major release, you
should add a footer with BREAKING CHANGE: [message]
feat(eslint): migrate to ESLint 8
Resolves #1
BREAKING CHANGE: see the ESLint 8 release notes for all breaking changes
In this example, the release notes would look like this:
- eslint: migrate to ESLint 8 ([commit-hash])
- eslint: see the ESLint 8 release notes for all breaking changes
To check for outdated dependencies, run:
npx npm-check-updatesThis lists which dependencies have updates. Unlike npm outdated,
npm-check-updates has a -u flag which conveniently updates package.json.
When updating packages, it's important to read the release notes for every updated package, including minor updates, as rules and extended configs may have changed.