build: generate CHANGELOG.md from conventional commits

[camcima]

Adds @release-it/conventional-changelog so every release updates a maintained CHANGELOG.md, instead of the history living only in GitHub release notes.

Follow-up to the v4.2.0 release.

What's here

• CHANGELOG.md, backfilled to v1.0.0. The plugin creates the file with full history on first release, but generating it now means the changelog exists today rather than after the next release.
• Plugin config in .release-it.json with explicitly declared preset types, so the output is deliberate rather than preset defaults: feat / fix / perf / revert get sections, docs and refactor appear without implying a bump (effect: "changelog"), and chore / ci / build / style / test are hidden.
• A "Releasing" section in CONTRIBUTING.md — the command, what it runs, the GITHUB_TOKEN requirement, and the --dry-run preview.
• CHANGELOG.md ships in the npm tarball (added to files), so it renders on the package page. Verified via npm pack --dry-run.

The version stays a manual decision

I set ignoreRecommendedBump: true, so pnpm release <version> still takes an explicit version rather than inferring one from commit types.

The v4.2.0 release is exactly why. Its one substantive commit was typed fix:, but it also added LockCanNotBeReleasedError, AmbiguousTransitionCandidate, and the Factory options template — so an inferred bump would have produced 4.1.1, when the correct answer was 4.2.0. Automatic versioning is only as good as commit-type discipline, and the semver call is worth keeping with a human. Flip the flag to false later if you'd rather have it inferred.

The same root cause produced one artifact worth flagging: the generated v4.2.0 entry was a single "Bug Fixes" line, with two malformed links (closes [53-#57](.../53-/issues/57)) parsed out of the #53-#57 ranges in the squash-commit body. I corrected that entry by hand to list the features and fixes accurately. The plugin only ever prepends new sections, so hand-corrected history is safe — noted in CONTRIBUTING.

Note on the lockfile diff

pnpm-lock.yaml is larger than the plugin alone accounts for: node_modules had release-it 20.2.1 installed while package.json has declared ^21.0.2 since #49 merged, so pnpm install also picked up that pending upgrade. Worth knowing that the v4.2.0 release was cut with 20.2.1.

Verification

pnpm lint clean · pnpm test 389/389 · pnpm format:check clean · npx release-it --dry-run resolves the plugin, computes the compare link, and reports "Writing changelog to CHANGELOG.md".

🤖 Generated with Claude Code

https://claude.ai/code/session_01JLxceiNFfXfpGoxdfQEZqw

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (ff9c708) to head (281af2d).
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff            @@
##              main       #66   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           62        62           
  Lines         1870      1870           
  Branches       277       277           
=========================================
  Hits          1870      1870           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.