Automate package publishing to npm from CI

[Naturalclar]

Summary

Publishing @react-native-menu/menu is currently a manual, local operation. This issue proposes moving it into a GitHub Actions workflow so releases are reproducible, gated on CI, and not dependent on one maintainer's machine or npm credentials.

Current state

The release tooling is already configured — only the automation is missing:

• package.json has a release script (release-it) with @release-it/conventional-changelog (angular preset), npm.publish: true, github.release: true, and a chore: release ${version} / v${version} commit-and-tag convention.
• publishConfig.access is public, and prepare runs bob build to produce lib/.
• .github/workflows/ci.yml only builds and checks (lint, tsc, android, ios × NewArch/OldArch). There is no publish workflow.

So today a release means a maintainer running yarn release locally with npm credentials on hand. Every published release is authored by @Naturalclar, and the most recent one is v2.0.0 (2025-09-10) — master has since accumulated user-facing changes (e.g. feat(ios): preferredElementSize #1202, fix: android build on Expo SDK 55+56 / RN 0.83 / Kotlin 2.x #1197) that are not on npm.

Proposal

Add a .github/workflows/release.yml that runs release-it in CI. Details worth deciding before implementation:

Trigger. Options are (a) workflow_dispatch with a version-bump input, keeping the release an explicit maintainer action but moving execution to CI; (b) publish on pushed v* tags; or (c) fully automatic release on every merge to master that contains a feat/fix commit. (a) is the smallest change from today's process and the easiest to roll back; (c) is the biggest behavioral shift and probably wants agreement first.

Authentication. Either an npm granular access token stored as an NPM_TOKEN repository secret, or npm's OIDC trusted publishing, which avoids a long-lived token in repo secrets and enables provenance attestation. The latter looks preferable if it composes cleanly with release-it's publish step — that compatibility should be verified during implementation rather than assumed. release-it also needs a GITHUB_TOKEN for the GitHub release step.

Gating. The publish job should depend on the existing CI jobs passing. The iOS/Android build jobs are the only real validation this repo has (src/__tests__/index.test.tsx is a placeholder), so skipping them at release time would defeat the purpose.

Build output. The workflow needs lib/ built before publish — files ships src, lib, android, ios, and the podspec. Worth confirming that prepare fires as expected under Yarn 4 (yarn@4.1.1) in the publish path, and that the packed tarball contains what the current manual release produces. A --dry-run publish diffed against the last release is a cheap way to check.

Note on a prerequisite

CONTRIBUTING.md states that "pre-commit hooks verify that your commit message matches this format," but there is no husky, lefthook, or commitlint configuration in the repo — so conventional commit messages are convention-only, not enforced. Since @release-it/conventional-changelog derives both the version bump and the changelog from commit messages, any automation that computes the version from history depends on that input being reliable. This matters most for trigger option (c) and least for (a), where the maintainer picks the bump explicitly.

Acceptance criteria

• A release workflow exists and can publish a version to npm without a maintainer running yarn release locally.
• Publishing is blocked unless lint, tsc, and the Android/iOS builds pass.
• The GitHub release and changelog are still generated, matching the current release-it output.
• The published tarball's contents match what the current manual process produces.
• CONTRIBUTING.md describes the new release process.