Zaileys ships releases as GitHub Releases only. Publishing to npm is a deliberate manual step performed by the maintainer — it is intentionally not automated.
# 1. Record the change set (choose bump: patch / minor / major)
pnpm changeset
# 2. Apply version bumps + update CHANGELOG
pnpm changeset version
pnpm install
# 3. Commit the version bump
git add -A
git commit -m "chore(release): version packages"
# 4. Tag the release (must match the new package.json version)
git tag vX.Y.Z
# 5. Push the tag — this triggers .github/workflows/release.yml
git push --tagsPushing a v* tag runs the Release workflow, which:
- builds the package (
pnpm build), - packs the tarball (
pnpm pack->zaileys-X.Y.Z.tgz), - creates a GitHub Release with autogenerated release notes and the tarball attached.
After the GitHub Release is created, publish to npm locally:
pnpm build
npm publish
# or: pnpm publishThis step is intentionally not in CI. No NPM_TOKEN lives in the CI pipeline; the npm release is a deliberate, user-attributed action (project policy / threat model T-08-05).
During the v4 cycle, .changeset/config.json uses "baseBranch": "v4". Once v4 merges to main, retarget it:
pnpm pkg --help >/dev/null # (config edit is manual)
# set .changeset/config.json "baseBranch" -> "main"The v4 -> main merge timing is maintainer-controlled.
Every PR that changes published behavior must include a changeset (enforced by .github/workflows/changeset-check.yml). Docs-only or chore PRs may add the no-changeset label to skip the check, or run pnpm changeset --empty.