Releasing

uris publishes one package. The application itself is not one of them — it holds a database and a search index, so it is deployed rather than installed.

Package	Tree	Registry
@uris-to/client	web/	npmjs.com

The loop

Releasing is two merges: yours, then the release pull request’s.

1. Land a commit on main with a conventional prefix.
2. release-please opens a release pull request. It bumps web/package.json and writes the changelog entry, and nothing else. It keeps rewriting itself as more commits land.
3. Merge it when you want to ship. That is the release decision, and the only manual step.
4. The merge is a push to main, so the workflow runs again — release-please sees its own pull request merged, cuts the tag and the GitHub release, and the publish job pushes to the registry in the same run.

It is one file, .github/workflows/release.yml, triggered by pushes to main.

Why the publish is chained rather than triggered by the tag

A tag pushed with GITHUB_TOKEN starts no workflow — GitHub suppresses it so a workflow cannot trigger itself. A separate workflow listening for client-v* would never fire. The publish job reads release-please’s own outputs instead, which needs no app token and no personal access token.

What counts as releasable

Only these five types are visible to release-please, from release-please-config.json:

feat  fix  perf  docs  refactor

Anything else — chore, ci, test, or a subject with no prefix at all — is invisible. It will not appear in a changelog and will not cause a release. A run that reports No user facing commits found is doing its job.

feat opens a minor bump, fix a patch. A ! after the type, or a BREAKING CHANGE: trailer, opens a major one. The package is below 1.0.0, where release-please treats a breaking change as a minor bump rather than a major one.

Tags

The tag carries the component, so the scheme has room for a second package later:

client-v0.1.0     @uris-to/client, from web/

The prefix comes from the component field in release-please-config.json, and release-please reads it back to work out what has already shipped. Nothing triggers on it.

The package is built, not committed

web/schema.graphql and web/src/generated/ are gitignored. The schema is dumped from the Ruby app and the typed documents are generated against it, so the publish job installs Ruby and runs the same three commands CI does before it packs anything:

bin/rails graphql:dump_schema
npm run codegen
npm run build:sdk

A checkout alone cannot build the package. That is deliberate: the documents cannot drift from the schema they were generated from.

Credentials

There are none, in the repository or in CI. npm publishes through OIDC trusted publishing: the job presents a short-lived GitHub identity token, and the registry decides whether it trusts it.

The registry is told four things:

Repository	urisrb/uris
Workflow	release.yml
Environment	npm
Package	@uris-to/client

All four are matched exactly and are case-sensitive. Renaming the workflow file, or changing the job’s environment:, breaks publishing until the registry is updated to match.

The npm CLI that ships on the runner is older than trusted publishing requires, so the job installs a current one first.

Publishing by hand

workflow_dispatch publishes without cutting a release — for the first publish, or to recover a version that failed after its tag was already cut:

gh workflow run release.yml -f package=client

It runs the same build and the same checks as the automatic path. It checks out main rather than a tag, so what it publishes is whatever version the tree currently declares.

What the repository needs

Two settings, neither of them in this tree:

• Actions may create pull requests. Under organization settings, not the repository’s — a repository cannot be more permissive than its organization, so the repository checkbox silently refuses to save while the organization has it off. Without it release-please cannot open the release pull request.
• A trusted publisher on npmjs, as above.