feat(cli): read pnpm's auth.ini for embedded package credentials [RED-891] [ship]

[sorccu]

Linear: RED-891

pnpm 11 moved pnpm login credentials out of .npmrc into auth.ini in pnpm's global config directory. Embedded package downloads only merged .npmrc files, so a logged-in pnpm user looked unauthenticated and embedding a private package failed with HTTP 404 — npm answers 404, not 401, for packages an unauthorized caller may not see, so the failure read as "this package does not exist".

Read pnpm's auth.ini

Resolves pnpm's config directory the way pnpm does (XDG_CONFIG_HOME/pnpm → macOS ~/Library/Preferences/pnpm → ~/.config/pnpm → Windows %LOCALAPPDATA%/pnpm/config; PNPM_HOME is deliberately not consulted — pnpm uses it only for data and state directories).

The file is always read; only its precedence depends on the lockfile: above the user .npmrc for pnpm projects, below it for others, mirroring pnpm's own order. Precedence is the load-bearing part — the reported failure was a stale .npmrc token being sent, so reading auth.ini without outranking that token would change nothing. Both end-to-end tests write a different token into each file and assert which one arrives; a fixture with a token in only one file passes under either ordering and cannot detect inverted precedence.

An unreadable auth.ini is skipped rather than fatal: unlike a .npmrc, it belongs to another tool and must not take the whole command down.

Say where the credentials came from

The hint now also fires on 404 (hedged — a 404 can equally mean the package is absent) and names the source. With credentials arriving from any of five places, "your credentials were rejected" without naming one leaves the reader as stuck as the bare status code:

Failed to download embedded package '@acme/private@1.2.3' from
'https://registry.npmjs.org' (HTTP 404). Credentials were sent but did not
grant access, so either the package does not exist or the credentials do not
cover it. They came from '//registry.npmjs.org/:_authToken' in '/Users/u/.npmrc'.

and when nothing matched, every place that was consulted:

… (HTTP 404). No credentials for this registry were found in 'npm_config_*
environment variables', '/repo/.npmrc', '/Users/u/.npmrc'. A registry may
answer 404 for a package you are not authorized to see, so the package may
exist but be invisible without credentials.

Both halves of a username/_password pair are named, since precedence is per key and the halves routinely live in different files — naming only the username points at the half that cannot expire. An environment variable is named by its verbatim spelling (NPM_CONFIG_REGISTRY, not the case-folded key). The same hint now also covers the registry-metadata request that yarn plans make, which authenticates identically.

Redirects. follow-redirects strips Authorization across hosts, so a tarball download that redirects to a CDN is answered by a host that never saw the credentials. Calling them rejected there would send someone to rotate a working token, so the hop is reported instead. Whether the header survived is observed from the post-strip options in beforeRedirect rather than re-derived from the library's policy — subdomain redirects keep it, protocol downgrades drop it regardless of host.

Never echo a URL that cannot be shown safely

A URL in an error is now rebuilt from scheme and host only. Userinfo, path, query and fragment are absent by construction rather than stripped: a registry URL may embed a token, a pre-signed CDN URL puts its signature in the query, and some registries take a token as a path segment. Anything that does not parse, or parses without a host, is withheld entirely — the rule rest/errors.ts already applies to proxy URLs.

This replaced a regex that tried to strip userinfo from malformed strings. Review found five ways past it (truncating at the first @, matching an empty userinfo, a host-less parse that left the credential in the path, an authority not at offset 0, and a query never considered), so the approach went rather than its fifth patch. Nothing is lost: the invalid-URL error now names the config key and file that produced the value, or the lockfile that recorded it, which is where the reader goes to fix it.

Reviewer notes

• loadNpmrcConfig returns {config, files, unreadable, origins} instead of a bare map, and resolveAuthHeader returns {header, keys} instead of a string. Both were needed to trace a credential back to its source.
• The message vocabulary lives in diagnostics.ts with a colocated spec. It is worth keeping it directly unit-tested: every one of the redaction leaks above was found by review rather than by the end-to-end tests that were the only coverage at the time.
• registryHttpError (added by feat(cli): prune the bundled lockfile to the code bundle's contents [RED-886] [ship] #1442) gained a hint callback so the download and metadata paths share one wrapper without sharing one fixed hint.
• Still to come on this branch: pnpm scope-qualified auth keys (//host/:@scope:_authToken, written by pnpm login --scope), and trailing-slash tolerance in the nerf-dart walk. Neither is started; resolveAuthHeader currently probes only slash-terminated darts and ignores the scope.

🤖 Generated with Claude Code

https://claude.ai/code/session_01LKwAcpVJCkJgK3yfxfSVqu

[github-actions]

Auto-approved: ship/show PR from a same-repo branch.