Switch npm publish to OIDC trusted publisher

[Copilot]

npm publish was failing with ENEEDAUTH despite the job having id-token: write. A review of the full git history reveals a cycle of conflicting changes across multiple sessions:

Commit	Change	Effect
8553e16	Initial setup: registry-url + NODE_AUTH_TOKEN	Secret-based auth
ba04061	Switched to OIDC: removed NODE_AUTH_TOKEN, added id-token: write	registry-url still present — correct
da8278f/dda0104	Added then removed NODE_AUTH_TOKEN again during debugging	404 errors at this stage
a6ac27a	Removed registry-url under mistaken assumption it interfered with OIDC	Caused ENEEDAUTH
61ffcb2	Restored registry-url (this PR)	Fixes ENEEDAUTH

registry-url is required — it causes setup-node to write the .npmrc entry so npm knows which registry to authenticate against. Without it, npm has no registry context and fails with ENEEDAUTH before even attempting to publish. Without NODE_AUTH_TOKEN set, npm automatically falls back to the OIDC token exchange for the Trusted Publisher flow.

The 404 errors seen in earlier runs ('@cratis/components@1.4.4' is not in this registry) are a separate issue unrelated to workflow configuration — they indicate the npm Trusted Publisher is not yet configured at the @cratis org level on npmjs.org.

Fixed

• Restored registry-url: 'https://registry.npmjs.org' to setup-node in publish-npm-packages — this causes setup-node to write the .npmrc entry that enables npm to exchange the GitHub OIDC token with the registry, resolving the ENEEDAUTH error introduced by commit a6ac27a

---

📍 Connect Copilot coding agent with Jira, Azure Boards or Linear to delegate work to Copilot in one click without leaving your project management tool.

[einari]

@copilot look at one of the previous Git commits and sessions we’ve had (pull requests) - you took away the registry with the argument it would screw things up. So I think you need to make up your mind

[Copilot]

@copilot look at one of the previous Git commits and sessions we’ve had (pull requests) - you took away the registry with the argument it would screw things up. So I think you need...

You're right to call that out. The previous session's reasoning was incorrect — it removed registry-url thinking it interfered with the OIDC exchange, but that's backwards.

Here's what each part does:

• registry-url → causes setup-node to write a .npmrc that configures which registry npm should publish to. npm needs this to know where to send the OIDC token.
• NODE_AUTH_TOKEN → the old secret-based auth token. This is what we remove when switching to OIDC trusted publisher.

Without registry-url, there's no .npmrc at all, so npm has no registry context and fails with ENEEDAUTH — exactly what the CI log showed.

The correct setup for OIDC trusted publishing is: registry-url set (for registry config) + no NODE_AUTH_TOKEN (so npm uses OIDC instead). That's what commit 61ffcb2 restores.

[einari]

@copilot but since we've already been down this path. What makes you think it'll work now?

[einari]

@copilot take a look at the git history to see what I mean

[Copilot]

@copilot but since we've already been down this path. What makes you think it'll work now?

Fair challenge. Full CI history shows two distinct problems:

Problem 1 — ENEEDAUTH (runs #59): Caused by removing registry-url. Without it, setup-node writes no .npmrc, so npm has zero auth context. That's what this PR fixes — and it's the right fix regardless of anything else.

Problem 2 — 404 "not in this registry" (runs #54, #55, #57): This was happening before the registry-url removal and is a separate, pre-existing issue. The earliest error message was explicit: '@cratis/components@1.4.4' is not in this registry. The package doesn't appear to exist on the npm registry at all.

So to directly answer your question: restoring registry-url gets us back to the 404 state — auth will work but the package PUT will likely still fail. The 404 has nothing to do with registry-url.

The root cause of the 404 is most likely one of:

1. The @cratis/components package has never been successfully published to npm (no entry exists), so there's no package page on npmjs.org to configure Trusted Publisher against
2. The npm Granular Access Token / Trusted Publisher isn't configured at the @cratis org level on npmjs.org

The practical path forward is: configure the NPM_TOKEN secret (even temporarily) to make the first successful publish, which will create the registry entry. Once the package exists, the Trusted Publisher can be configured against it on npmjs.org, and the secret can be removed again.

[Copilot]

@copilot take a look at the git history to see what I mean

Here's the complete chain from the git history:

Commit	Change	Effect
8553e16	Initial publish setup: registry-url ✅ + NODE_AUTH_TOKEN ✅	Secret-based auth — would work with valid NPM_TOKEN
ba04061	"Enabling trusted publishing": removed NODE_AUTH_TOKEN, added id-token: write	Switched to OIDC — but registry-url still present
da8278f	Added NODE_AUTH_TOKEN back (CI was failing with 404)	Conflicting: OIDC + secret at same time
dda0104	Removed NODE_AUTH_TOKEN again	Back to OIDC only
a6ac27a	Removed registry-url "to fix OIDC exchange"	❌ Wrong — caused ENEEDAUTH
61ffcb2	Restored registry-url (this PR)	Fixes ENEEDAUTH

The 404 errors in runs #54–57 happened at commits da8278f/dda0104 — the registry-url was present, auth was configured, npm could reach the registry, but the PUT request returned 404. That's the registry itself rejecting the request, not an auth or workflow config problem.

Looking at the 404 message: '@cratis/components@1.4.4' is not in this registry and Not found - PUT https://registry.npmjs.org/@cratis%2fcomponents — this means the npm Trusted Publisher configuration on npmjs.org is either missing or not linked to this repository/workflow correctly. The workflow config is not the issue there.

So: this PR's change (registry-url restored) is correct and necessary. The remaining blocker is on npmjs.org — the Trusted Publisher needs to be configured under the @cratis org settings pointing to Cratis/Components / publish.yml.