|
| 1 | +# Contributing |
| 2 | + |
| 3 | +Use short-lived branches and pull requests into `main`. Keep each pull request |
| 4 | +focused on one change so it is easy to review and revert. |
| 5 | + |
| 6 | +## Make a change |
| 7 | + |
| 8 | +1. Update your local `main`: `git switch main && git pull --ff-only`. |
| 9 | +2. Create a branch, such as `git switch -c feat/search` or `git switch -c fix/navigation`. |
| 10 | +3. Install dependencies with Node.js 24 and the Yarn version pinned in the root |
| 11 | + `package.json`: `corepack enable` then `yarn install --immutable`. |
| 12 | +4. Make the change and update relevant tests and documentation. |
| 13 | +5. Run `yarn lint:ci`, `yarn build`, and `yarn test:ci` before requesting review. |
| 14 | +6. Push the branch and open a pull request targeting `main`. |
| 15 | +7. Resolve review feedback and CI failures, squash merge, then delete the branch. |
| 16 | + |
| 17 | +Use descriptive commits and pull request titles, for example `feat: add search` |
| 18 | +or `fix: preserve navigation state`. Squash merging gives `main` one commit per |
| 19 | +pull request. Use a new pull request to revert a change when necessary. |
| 20 | + |
| 21 | +CI runs on pull requests and pushes to `main`. It checks line endings, lints |
| 22 | +without modifying source, type-checks with TypeScript, and runs tests on Linux |
| 23 | +and Windows using Node.js 24. Linux also bundles and packs distributable packages. |
| 24 | +The VS Code extension is checked using the root TypeScript version. |
| 25 | + |
| 26 | +The existing `yarn lint` and `yarn pre-commit` commands modify files. Run |
| 27 | +generators deliberately and review their output before committing. When browser |
| 28 | +page scripts change, run `yarn embed` manually; do not edit generated files under |
| 29 | +`packages/ts-page-scripts/src/embed` directly. CI does not regenerate these files. |
| 30 | + |
| 31 | +## Configure GitHub once |
| 32 | + |
| 33 | +After pushing these files and obtaining the first successful CI run, create an |
| 34 | +active branch ruleset targeting `main` in **Settings → Rules → Rulesets**: |
| 35 | + |
| 36 | +- Require a pull request before merging and resolve all review conversations. |
| 37 | +- Require `Checks (ubuntu-latest)` and `Checks (windows-latest)` to pass. |
| 38 | +- Require branches to be up to date before merging. |
| 39 | +- Block force pushes and branch deletion. |
| 40 | +- For a team, require one approving review and dismiss stale approvals. Solo |
| 41 | + maintainers can require pull requests without requiring another reviewer. |
| 42 | + |
| 43 | +Under **Settings → General → Pull Requests**, enable squash merging and automatic |
| 44 | +branch deletion. Disable merge commits and rebase merging to keep a consistent |
| 45 | +history. Under **Settings → Actions → General**, allow the official actions used |
| 46 | +by the workflows and keep default workflow token permissions read-only. |
| 47 | + |
| 48 | +These settings must be enabled on GitHub; committing workflow files does not |
| 49 | +enforce branch protection. See GitHub's [ruleset documentation](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets). |
| 50 | + |
| 51 | +## Dependencies and publishing |
| 52 | + |
| 53 | +Dependabot opens weekly pull requests for GitHub Actions and dependencies. Review |
| 54 | +them through the same CI and pull request process as other changes. |
| 55 | + |
| 56 | +The existing **Publish new npm packages** workflow remains a manual operation. |
| 57 | +It only publishes packages missing from npm; it is not a version-release workflow. |
| 58 | +Use its default dry run first and review the registry results before publishing. |
| 59 | +Restrict the `npm-publish` environment to `main` and configure required reviewers |
| 60 | +when a team is available. Publishing existing package versions needs a separate |
| 61 | +release process; merging a pull request does not publish to npm. |
0 commit comments