ci(publish): switch to npm OIDC trusted publishing - #86
Conversation
The package has a Trusted Publisher configured on npmjs.com (berget-ai/cli / publish.yml), but the workflow still authenticated with the classic NPM_TOKEN — which has since expired, making npm publish fail with a misleading 404. Trusted publishing needs id-token: write and npm >= 11.5.1; no token secret required.
![berget-ai[bot]](https://avatars.githubusercontent.com/u/160869282?s=60&v=4){kind=small}
There was a problem hiding this comment.
[Tools used: verified only publish.yml references NPM_TOKEN/id-token in the repo; package.json shows a public, unscoped package ("private": false, publishConfig.access: public) whose npm 2.2.22 publishes come straight from this workflow; root .npmrc only sets legacy-peer-deps, so publish auth is unaffected. The npm ≥ 11.5.1 requirement for OIDC trusted publishing in the comment matches npm's own changelog/docs (npm v11.5.1, July 2025, added trusted publishing for GitHub Actions), and Node 22's bundled npm 10.x makes the global upgrade genuinely necessary.]
Review
Summary
Switches publish.yml from a long-lived classic NPM token to npm OIDC trusted publishing (id-token: write, no NODE_AUTH_TOKEN) with a global npm upgrade to satisfy the ≥ 11.5.1 requirement.
Risk
LOW — the change is small, matches npm's documented trusted-publishing setup, and strictly reduces standing credentials; the main residual risk is the unpinned npm@latest on the release path.
Issues
- warning
.github/workflows/publish.yml:81—npm install -g npm@latestis unpinned, so every release pulls whatever npm shipped minutes earlier; a new npm major (or a bad/compromised release) with higher Node engine requirements can break or be abused in the publish environment. Pin a known-good version, e.g.npm install -g npm@11.5.1(ornpm@^11.5.1). - good
.github/workflows/publish.yml:47— replacing the expired long-livedNPM_TOKENwith short-lived OIDC trusted publishing removes a standing credential from the repo, the right security posture.
Suggestions
.github/workflows/publish.yml:81— usenpm install -g npm@11.5.1(or a caret range likenpm@^11.5.1) instead ofnpm@latestto keep releases reproducible and immune to future npm majors that drop Node 22 support.
Architecture
No structural change; scope of id-token: write is correctly limited to the publish job, not the whole workflow.
CodeSense
8/10 — concise, well-commented, and follows the official npm trusted-publishing recipe; docked a point only for the non-reproducible unpinned npm upgrade on the release path.
Inline findings
Berget AI (berget/zai-org/GLM-5.3-Flash) | PR #86
| NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }} | ||
| - name: Publish to NPM (OIDC trusted publishing) | ||
| run: | | ||
| npm install -g npm@latest # OIDC trusted publishing needs npm >= 11.5.1 |
There was a problem hiding this comment.
🟠 warning — npm install -g npm@latest is unpinned — a new/bad npm release can break (or compromise) the publish step; pin e.g. npm@11.5.1 or npm@^11.5.1.
| # OIDC trusted publishing (npmjs.com → berget → Trusted Publisher: | ||
| # berget-ai/cli / publish.yml). No NPM_TOKEN needed — the old classic | ||
| # token expired, which made npm publish fail with a misleading 404. | ||
| id-token: write |
There was a problem hiding this comment.
✅ good — Dropping the long-lived NPM_TOKEN in favor of short-lived OIDC trusted publishing is the right security posture.
1 participant
npm publish failed with 404 on PUT: the package
bergethas a Trusted Publisher configured on npmjs.com (berget-ai/cli / publish.yml), and the classicNPM_TOKEN(set 2026-05-21, last successful publish 2026-06-16) has since expired — npm masks unauthorized publishes as 404.Switches the publish step to OIDC trusted publishing:
id-token: write+ npm ≥ 11.5.1, no token secret. Matches the already-configured trusted publisher entry exactly.