Npm Trusted publishing setup — check your npm release setup online

Sixteen findings, six of them blocking, came back from a twenty-five line release workflow - the file a Node package maintainer in Berlin gets when they ask a coding assistant for "a GitHub Action that publishes my package to npm".

Nothing in that workflow is broken today. It checks out the repository, installs, builds, and runs npm publish with NODE_AUTH_TOKEN read from a repository secret. That is exactly what makes it expensive: the file keeps passing CI right up to the morning it answers E401 Unauthorized, and that morning is not one you picked.

Here is what moved underneath it. npm revoked every classic token on 2025-12-09. The replacement - a granular access token with write scope - cannot be given a lifetime longer than 90 days, so a token minted on 2026-09-14 stops working on 2026-12-13 whether or not a release is planned that week. There is a different shape: OIDC trusted publishing, where GitHub Actions or GitLab CI mints a credential for one run, so nothing in your repository can expire or leak.

Coding assistants write the old shape because the old shape is what a decade of public workflows looks like. The secret block, the .npmrc echo, the --otp flag: all of it was correct advice for years, and all of it is now the reason a release stops.

npm Trusted Publish Lint reads the file you have open and reports the lines, not a score. Fifteen rules, in five groups. Credential: a stored npm token in the job environment, an _authToken line written into .npmrc, a literal npm_ token committed to the file, a one-time password passed on the command line. OIDC readiness: no id-token: write anywhere in a file that publishes, no environment binding on the publish job, an npm CLI pinned to 10 or older when trusted publishing needs 11.5.1. Blast radius: permissions: write-all, a pull_request_target trigger in a file that can publish, an action pinned to a moving ref like @main. Job hygiene: an install that runs dependency lifecycle scripts beside the publish credential, a curl piped into a shell, a plain http registry URL, a job still on Node 18. Attestation: npm publish without --provenance, so the tarball on the registry carries no signed link back to the run that built it.

On the sample file the six blocking findings are concrete. permissions: write-all becomes contents: read at the top and id-token: write on the publish job. The http registry URL becomes https. The .npmrc echo disappears entirely. The missing id-token: write is added. NODE_AUTH_TOKEN with a repository secret gives way to a credential the runner mints for the run.

The same file rewritten that way returns zero findings. That is the whole point of a line-level check: you can tell when you are finished.

Why not npm audit? npm audit reads your dependency tree; it never opens your workflow. A secret scanner fires only on a literal token you committed. Neither one knows the date the classic tokens died or the ceiling on the token that replaced them.

The check is free - all fifteen rules, every line, every file you open, in the editor or in the browser, no key and no account. The paid layer changes what you take away rather than what you are allowed to see: it sweeps every workflow in the repository in one pass and writes the audit to a dated Markdown or CSV file. $29 once.

For scale: a freelance DevOps engineer is a median $60 an hour on Upwork, with the usual range running $40 to $100. Reading one release workflow line by line, checking it against npm's current token rules and rewriting it for OIDC is most of an hour.