ci: automate npm releases with release-please - #209
Merged
Merged
Conversation
The npm package's last published version is 3.0.1; 4.0.0 is not yet on npm. release-please owns versioning from here: the manifest is seeded at 3.0.1 (and package.json set back to it), and a per-package `release-as` override drives the first release to 4.0.0. The override is needed because the breaking commit predates the javascript/ move, so release-please's path-based commit analysis wouldn't attribute it to the package and compute 4.0.0 on its own. `release-as` does not clear itself and must be removed once 4.0.0 ships.
On every push to main, release-please maintains a release PR; when a release is created, a gated job publishes to npm via OIDC trusted publishing so no long-lived token is stored. The per-package outputs are keyed by the package path (`javascript--release_created`).
Base automatically changed from
refactor/monorepo-package-separation
to
main
September 1, 2026 10:21
tvdeyen
marked this pull request as ready for review
September 1, 2026 10:21
tvdeyen
force-pushed
the
chore/release-please-npm
branch
2 times, most recently
from
September 1, 2026 10:29
8977b3a to
9013474
Compare
tvdeyen
added a commit
that referenced
this pull request
Sep 1, 2026
Fixes the stuck first release. After #209 merged, release-please ran but **skipped** — its path-scoped scan of `javascript/` found only `refactor`/`docs`/`ci`/`build` commits since `package-v3.0.1` ("No user facing commits found - skipping"), and the config `release-as` set the version but didn't override that skip. This forces the first release with a `Release-As: 4.0.0` footer on a commit that touches `javascript/` (so it's attributed to the package), which release-please honours by opening a release PR for that exact version. It also seeds `javascript/CHANGELOG.md` and drops the now-redundant config `release-as` (the footer is one-time and needs no later cleanup).⚠️ **Merge so the `Release-As: 4.0.0` line stays in the commit message on `main`** — release-please reads it from the merged commit. A merge commit preserves it verbatim; a squash merge keeps it as long as the footer remains in the squash commit body (it's there by default for this single-commit PR — just don't strip it). After this merges, release-please should open a `4.0.0` release PR; merging that tags `package-v4.0.0` and publishes `4.0.0` via OIDC.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stage 2 of the monorepo reorganization — the npm release automation. Stacked on #208 (the move); this PR's diff is only the release-please machinery. Retarget its base to
mainonce #208 merges.Adds release-please as a single, path-scoped component: it tags
package-vX.Y.Z— continuing the existingpackage-v1.2.0 … package-v3.0.1series, separate from the gem'svX.Y.Z— maintainsjavascript/CHANGELOG.md, and publishes to npm via OIDC trusted publishing (no stored token).The manifest is seeded at the last published version
3.0.1, and a per-packagerelease-as: "4.0.0"makes release-please's first release publish4.0.0(which is not on npm yet). The override is necessary because the breakingchore(npm)!commit predates thejavascript/move, so release-please's path-based commit analysis wouldn't attribute it to the package and compute4.0.0on its own.Around merge
release-please.yml).4.0.0release PR; merging it tagspackage-v4.0.0and publishes4.0.0.release-asfromrelease-please-config.jsonafter that PR merges — it does not self-clear, or it will keep forcing4.0.0.RSpec,Standard,Build,Vitest,Prettier).