3.3.1 published 8 of 9 packages: @useupup/server fails npm OIDC with ENEEDAUTH, so no tags and no GitHub Release

[BSalaeddin]

What happened

3.3.1 is a partial release. Eight of the nine publishable packages are on npm; @useupup/server@3.3.1 is not, and because changeset publish exited non-zero the job's last step never ran — so no package git tags were pushed and there is no v3.3.1 GitHub Release.

On npm at 3.3.1	core, react, vue, svelte, vanilla, angular, preact, next
Missing	@useupup/server (registry returns 404 for 3.3.1)
Git tags *@3.3.1	none pushed
GitHub Release	latest is still v3.3.0

The error, twice

Run 34586211004, original and re-run — identical:

🦋  error an error occurred while publishing @useupup/server: ENEEDAUTH
     This command requires you to be logged in to https://registry.npmjs.org
     You need to authorize this machine using `npm adduser`
🦋  error packages failed to publish:
🦋  @useupup/server@3.3.1

The re-run is the useful half: changeset publish skipped the eight already on npm and attempted only @useupup/server, from the same job, same runner, same id-token: write, same npm 11.16.0 on Node 22.14.0 — and failed the same way. So this is not transient and not a workflow ordering problem. Every other package authenticated over OIDC in that very run.

What it points at

publish.yml documents the precondition: "every @useupup package has its trusted publisher configured on npmjs.com (repo DevinoSolutions/upup, workflow publish.yml, configured 2026-08-01)". Eight packages behave as though that is true and one does not, which reads as @useupup/server's trusted publisher entry on npmjs.com being absent, pointing at a different repo/workflow, or having been reset. 3.3.0 published fine on 2026-09-02, so whatever changed is on the registry side since then. npm's own notice in the same log (npm tokens that bypass 2FA are being restricted…) is worth a look while you are in there.

This needs the npm account owner — it cannot be fixed from this repository.

To finish 3.3.1 once it is fixed

Re-run the publish job on 34586211004. changeset publish skips the eight, publishes server, and the final step then pushes the tags and cuts the v3.3.1 Release.

Not blocked by this

Consumers of @useupup/core / @useupup/react are fine — 3.3.1 is live and installs. Only server-mode consumers are stuck on 3.3.0.

[BSalaeddin]

Partial repair done: the eight published packages now have their 3.3.1 git tags. Pushed against 141f0e12 (the Version Packages merge on master, where every package.json reads 3.3.1), annotated, matching the shape changeset publish creates and the existing @useupup/*@3.3.0 tags:

@useupup/angular@3.3.1   @useupup/core@3.3.1     @useupup/next@3.3.1
@useupup/preact@3.3.1    @useupup/react@3.3.1    @useupup/svelte@3.3.1
@useupup/vanilla@3.3.1   @useupup/vue@3.3.1

@useupup/server@3.3.1 is deliberately NOT tagged. It did not publish, so a tag would assert something untrue and would make the gap invisible to exactly the tooling that maps a published version back to a commit.

The v3.3.1 GitHub Release is deliberately NOT cut, and this is the part I would rather a human decided. Cutting it would mark as "Latest" a release that is missing a package and whose sharedDrives path is already under REQUEST CHANGES review — listSharedDriveFolders() is awaited unguarded in loadFiles, so a non-2xx from drives.list destroys the whole root listing for anyone with the flag on. A 3.3.2 carrying that fix is being prepared. The honest options are to fold 3.3.1 into the 3.3.2 release notes, or to cut a 3.3.1 Release that says plainly what is missing and what is fixed in 3.3.2. Either is a maintainer call; the tags above are the part that is purely factual.

Still owner-only, unchanged: the @useupup/server trusted-publisher entry on npmjs.com. Everything in this comment needed only GITHUB_TOKEN.

[BSalaeddin]

Maintainer decision: no v3.3.1 GitHub Release will be cut — the 3.3.2 Release notes will record that 3.3.1 published core/react/vue/svelte/vanilla/angular/preact/next only, that @useupup/server did not publish (this issue), and that 3.3.2 hardens the sharedDrives root listing (guarded drives.list, escaped ids, rows first).

[BSalaeddin]

Recurred identically on 3.3.2 (run 34591681494, commit b3d23b6b): the other eight packages published at 3.3.2, @useupup/server failed the same ENEEDAUTH, so npm still serves @useupup/server@3.3.0 and the job's tag/Release step was skipped again. I pushed the eight @useupup/*@3.3.2 tags by hand and cut v3.3.2, whose notes state plainly that server is not published at this version and link here.

[BSalaeddin]

Repeated on 3.3.3 (publish run 34602580776): the same eight packages published and @useupup/server failed ENEEDAUTH again, so it is still on 3.3.0 while the other eight are on 3.3.3. Third release in a row. The tag step is if: the publish succeeded, so the eight package tags and the v3.3.3 Release were created by hand again — which is the recurring cost of leaving this open.