Background
The npm registry and most pnpm-compatible private registries authenticate requests via credentials configured in .npmrc: per-registry bearer tokens (//registry.example.com/:_authToken=...), basic auth (_auth, or username + _password), and the always-auth setting. Credentials may be expanded from environment variables (e.g. ${NPM_TOKEN}). pnpm resolves these across global, user, project, and workspace .npmrc scopes and attaches the appropriate Authorization header to every registry request — metadata fetches and tarball downloads alike, even when the tarball is served from a different host than the metadata endpoint.
pacquet parses some auth fields in crates/npmrc/src/npmrc_auth.rs but does not currently apply them on outgoing requests in crates/network, crates/registry, or crates/tarball. As a result, pacquet install against private registries does not work the way pnpm install does.
Tasks
Examine pacquet's own codebase to see what auth handling already exists and where it stops short — config parsing, request construction in crates/network, and the metadata and tarball code paths in crates/registry and crates/tarball.
Research the pnpm codebase. Understand how .npmrc auth fields are parsed and merged across scopes, how a credential is selected for a given URL, how environment variable expansion works, how always-auth is honored, and how auth headers are attached to tarball hosts that differ from the metadata host.
Examine the accuracy of the claims in Background.
Implement this feature for pacquet install. Exactly as how pnpm implemented it. Match pnpm's auth field selection, URL matching, env expansion, and the error codes surfaced on 401/403.
Test coverage and the dependency injection pattern
After implementing the feature, check whether the new code introduces any uncovered coverage holes (for example, code paths that depend on environment variables, the global filesystem, or live network state — things that are awkward to exercise from a plain unit test).
If it does, refactor the new code to take its environment as injected parameters rather than reading globals directly, so the tests can drive every branch with local values. The dependency-injection pattern discussed in the comments below is the reference for how to do this in pacquet:
If the tests already cover every branch of the new code without DI (i.e. no new coverage holes), then the DI refactor is unnecessary and should be skipped.
Requirements
Mirror pnpm v11.
Carefully read and abide by the following files:
AGENTS.mdCONTRIBUTING.mdCODE_STYLE_GUIDE.mdplans/PORTING_GUIDE.md
If the porting guide needs to be updated, update it accordingly.
Background
The npm registry and most pnpm-compatible private registries authenticate requests via credentials configured in
.npmrc: per-registry bearer tokens (//registry.example.com/:_authToken=...), basic auth (_auth, orusername+_password), and thealways-authsetting. Credentials may be expanded from environment variables (e.g.${NPM_TOKEN}).pnpmresolves these across global, user, project, and workspace.npmrcscopes and attaches the appropriateAuthorizationheader to every registry request — metadata fetches and tarball downloads alike, even when the tarball is served from a different host than the metadata endpoint.pacquetparses some auth fields incrates/npmrc/src/npmrc_auth.rsbut does not currently apply them on outgoing requests incrates/network,crates/registry, orcrates/tarball. As a result,pacquet installagainst private registries does not work the waypnpm installdoes.Tasks
Examine
pacquet's own codebase to see what auth handling already exists and where it stops short — config parsing, request construction incrates/network, and the metadata and tarball code paths incrates/registryandcrates/tarball.Research the
pnpmcodebase. Understand how.npmrcauth fields are parsed and merged across scopes, how a credential is selected for a given URL, how environment variable expansion works, howalways-authis honored, and how auth headers are attached to tarball hosts that differ from the metadata host.Examine the accuracy of the claims in Background.
Implement this feature for
pacquet install. Exactly as howpnpmimplemented it. Match pnpm's auth field selection, URL matching, env expansion, and the error codes surfaced on 401/403.Test coverage and the dependency injection pattern
After implementing the feature, check whether the new code introduces any uncovered coverage holes (for example, code paths that depend on environment variables, the global filesystem, or live network state — things that are awkward to exercise from a plain unit test).
If it does, refactor the new code to take its environment as injected parameters rather than reading globals directly, so the tests can drive every branch with local values. The dependency-injection pattern discussed in the comments below is the reference for how to do this in
pacquet:.modules.yaml#332 (comment).modules.yaml#332 (comment)If the tests already cover every branch of the new code without DI (i.e. no new coverage holes), then the DI refactor is unnecessary and should be skipped.
Requirements
Mirror pnpm v11.
Carefully read and abide by the following files:
AGENTS.mdCONTRIBUTING.mdCODE_STYLE_GUIDE.mdplans/PORTING_GUIDE.mdIf the porting guide needs to be updated, update it accordingly.