Background

#490 landed cafile=<path> handling. The current implementation reads the file via std::fs::read_to_string(path), which resolves relative paths against the process cwd. This matches pnpm's behavior exactly — pnpm's loadCAFile also passes the path straight to fs.readFileSync without path.resolve, and pnpm doesn't process.chdir(opts.dir) on --dir.

The result: with pacquet --dir /project install from /home/user, a project .npmrc containing cafile=certs/ca.pem reads /home/user/certs/ca.pem instead of /project/certs/ca.pem, silently dropping the CA list when it isn't found. Surprising and footgun-y for --dir invocations.

Documented as a parity quirk in crates/config/src/npmrc_auth.rs:load_cafile (see the long comment at SHA 55083a4).

What to do

This is upstream's quirk — pacquet matches pnpm bug-for-bug per AGENTS.md's cardinal rule. The correct sequence:

1. File an issue against pnpm/pnpm describing the problem (cafile relative paths surprise users with --dir).
2. If upstream accepts and lands a fix (most likely: resolve cafile against the directory the .npmrc was read from), port the change into pacquet's load_cafile.
3. Drop the parity-quirk paragraph from the load_cafile doc comment.

Alternatively, if upstream rejects (e.g. "we don't want to change long-standing behavior"), keep pacquet matching but consider documenting the quirk in the user-facing docs (the pnpm.io cli page if pacquet documents there) and the workarounds (absolute path, cd first, or use inline ca=).

Out of scope

• Diverging from pnpm without an upstream fix landing first. AGENTS.md is explicit: "Do not 'fix' pnpm quirks unless the same fix has landed upstream."

References

• pnpm v11 SHA 94240bc046
• pacquet feat(config,network,cli): TLS keys + local-address from .npmrc #490 — top-level TLS keys (where this was first documented)
• CodeRabbit discussion thread flagging the quirk

Written by an agent (Claude Code, claude-opus-4-7).