Skip to content

Tags: sledorze/cairn

Tags

v0.14.0

Toggle v0.14.0's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
Version Packages (#194)

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

v0.13.2

Toggle v0.13.2's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
Version Packages (#192)

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

v0.13.1

Toggle v0.13.1's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
Version Packages (#189)

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

v0.13.0

Toggle v0.13.0's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
fix: publish auth -- add .npmrc for NPM_TOKEN, closing the ENEEDAUTH …

…the last real run hit (#186)

The publish-script fix (#182) got past the input-rename error, into a
real publish attempt -- and confirmed the exact gap that PR's own
comment had disclosed as unverified: `gh run view` on the real failed
run (2026-08-20T14:44Z) shows `changeset publish` failing with
`ENEEDAUTH: This command requires you to be logged in to
https://registry.npmjs.org/`, even with NPM_TOKEN correctly set as an
env var in the workflow.

Root cause: changesets/action v1 auto-wrote its own .npmrc from
NPM_TOKEN; v2 doesn't (confirmed by grepping v2.1.0's real bundled
dist/*.js -- zero references to NPM_TOKEN or .npmrc anywhere, and its
README points at Trusted Publishing instead, with no classic-token
guidance at all). npm never associates an env var with a registry on
its own -- something has to write that mapping, and after the v1->v2
bump, nothing did.

Fixed with a repo-root .npmrc (the standard npm token-substitution
pattern, //registry.npmjs.org/:_authToken=${NPM_TOKEN}), verified for
real: with a fake NPM_TOKEN set, `npm whoami`/`pnpm whoami` against the
REAL registry.npmjs.org now return 401 Unauthorized (proving the token
is read and sent) instead of ENEEDAUTH (proving it wasn't) -- the exact
diagnostic signature that distinguishes "wrong token" from "no auth
configured at all." Traced changeset publish's real code path too, not
assumed: @changesets/cli detects this as a pnpm project and spawns
`pnpm publish` with cwd at the repo root -- exactly where .npmrc lives.

Harmless where NPM_TOKEN is unset (every local dev machine): pnpm
prints a non-fatal WARN, confirmed not to block install/typecheck/
test/check -- only resolves for real in CI, where the secret is set.

Also updates release.yml's own NPM_TOKEN comment, which had explicitly
disclosed this as an open, unverified question -- now states what
actually happened (the real ENEEDAUTH failure) and points at this
file's own fix.

Adversarially reviewed: verdict PASS, no issues found. The reviewer
reproduced the fake-token E401 test independently, traced
@changesets/cli's real getPublishPlan code path (not assumed),
cross-checked the updated comment against the actual failed run's real
log, and confirmed no secret-exposure risk (.npmrc stays a template
string; nothing writes a resolved value back to it). One residual,
unavoidable risk flagged, not a defect in this diff: this proves the
AUTH MECHANISM is wired correctly, not that the NPM_TOKEN secret
itself is valid/unexpired -- the next real workflow run is still the
first true end-to-end confirmation of that.

pnpm typecheck && pnpm test (1147/1147) && pnpm check all green.

Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>