Skip to content

Publish OpenAPI spec to npm via OIDC trusted publishing#19

Merged
gjtorikian merged 3 commits intomainfrom
publish-da-spec
May 4, 2026
Merged

Publish OpenAPI spec to npm via OIDC trusted publishing#19
gjtorikian merged 3 commits intomainfrom
publish-da-spec

Conversation

@gjtorikian
Copy link
Copy Markdown
Collaborator

Summary

  • New release.yml workflow publishes @workos-inc/openapi-spec on every spec change to main (or manual dispatch), bumping the minor version against the registry and tagging a GitHub Release with the spec attached.
  • Uses npm OIDC trusted publishing (id-token: write + --provenance) so no NPM_TOKEN secret lives in the repo — only the trusted-publisher config on npmjs.com.
  • The workflow builds a fresh dist/package.json for publishing; the root package.json stays private: true as dev tooling, and its runtime deps are reclassified as devDependencies to reflect that.
  • README adds an Installation section showing how to install the package and load the spec from Node (ESM/CJS) or bundlers.

Bootstrap

The trusted publisher cannot be configured until the package exists on npm. One-time bootstrap:

  1. Build the dist payload locally with version: 0.0.1 (mirrors the workflow's Assemble step).
  2. npm publish --access public with a personal token / npm login.
  3. Configure Trusted Publishers on npmjs.com pointing at this repo + workflow filename release.yml.
  4. Revoke the bootstrap token. From here on, the workflow takes over and the first auto-release is 0.1.0.

Test plan

  • Bootstrap 0.0.1 to npm manually and configure the trusted publisher.
  • Trigger release.yml via workflow_dispatch and confirm it publishes 0.1.0 without a token.
  • Confirm the git tag v0.1.0 and the GitHub Release (with open-api-spec.yaml attached) are created.
  • Verify the npm package contains only open-api-spec.yaml, package.json, LICENSE.txt, README.md.
  • Merge a spec-only change to main and confirm the workflow auto-publishes 0.2.0.

gjtorikian added 3 commits May 4, 2026 16:37
The root package.json is private dev tooling; the npm publish
workflow builds a fresh dist/package.json containing only the
spec. Nothing under "dependencies" was actually consumed at
runtime, so reclassifying them as devDependencies prevents
misleading supply-chain tooling and clarifies that consumers
should install the published @workos-inc/openapi-spec package
instead of this repo.
SDK consumers and external integrators need a versioned,
addressable artifact for the WorkOS spec rather than pulling
from a moving git ref. OIDC trusted publishing keeps long-lived
npm tokens out of the repo: GitHub Actions exchanges its OIDC
identity for short-lived publish credentials, so the only
secret to manage is the trusted-publisher config on npmjs.com.

The workflow runs on spec changes to main (and on manual
dispatch), bumps the minor version against whatever is on the
registry, and emits both a git tag and a GitHub Release with
the spec attached for non-npm consumers. README documents how
to install and load the published package.
SDK consumers writing TypeScript want compile-time guarantees
on request and response shapes; without published types they
either copy-paste interfaces or pull the spec at build time
themselves. Generating types as part of the publish workflow
makes the same artifact serve both the YAML and the typed
client use cases, in lockstep with the spec version.

Uses openapi-typescript v7 (run via npx to avoid its TS ^5
peer-dep conflict with the repo's TS ^6) to emit a single
types.d.ts with the standard paths/components/operations
exports. The published package.json gains an exports map so
TypeScript resolves "@workos-inc/openapi-spec" to the types
while runtime resolution of "@workos-inc/openapi-spec/spec"
still returns the YAML file path.
@gjtorikian gjtorikian merged commit 26ddf53 into main May 4, 2026
5 checks passed
@gjtorikian gjtorikian deleted the publish-da-spec branch May 4, 2026 23:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant