Install dependencies and run the full build and test suite before opening a pull request:
pnpm install --frozen-lockfile
pnpm testPull requests run the same checks with GitHub Actions.
This repository uses Conventional Commits to determine the next Semantic Version:
| Commit | Release | Example |
|---|---|---|
| Bug fix | Patch | fix: preserve cached-search cursor |
| New backward-compatible feature | Minor | feat: add destination search |
| Breaking API change | Major | feat!: rename flight-search inputs |
Use a BREAKING CHANGE: footer when the reason or migration guidance needs
more detail. Documentation, tests, refactoring, and maintenance commits can use
their corresponding types (docs:, test:, refactor:, and chore:); these
do not create a release unless they contain a breaking-change marker.
- Merge conventional commits into
main. - The
Release Pleaseworkflow creates or updates one release PR. - Review the generated version,
CHANGELOG.md, and package metadata. - Merge the release PR when the accumulated changes are ready to ship.
- Release Please creates the
vX.Y.Ztag and a published GitHub Release from the changelog entry.
Do not manually edit the package version or add an unreleased changelog heading
in feature pull requests. Release Please owns those changes. The current
released version is bootstrapped in .release-please-manifest.json; after the
first automated release, that file is maintained by Release Please.
Repository administrators must allow GitHub Actions to create pull requests in
Settings > Actions > General > Workflow permissions. The workflow uses the
built-in GITHUB_TOKEN by default. If checks or other workflows must run on the
release PR itself, add a fine-grained personal access token or GitHub App token
as the RELEASE_PLEASE_TOKEN Actions secret, because events created by the
built-in token do not start additional workflow runs.