Walkthrough

Project/workspace-controlled registry/proxy destination URLs and registry credential values with ${...} placeholders are ignored (dropped + warned). Trusted/global/user/CLI sources continue to expand placeholders. Changes span JS config/reader, Rust npmrc parsing, workspace YAML substitution, tests, CLI integration tests, and a changeset.

Changes

Registry Environment Variable Placeholder Handling

Sequence Diagram(s)

sequenceDiagram
  participant WorkspaceYAML as pnpm-workspace.yaml
  participant ProjectNpmrc as Project .npmrc
  participant UserNpmrc as User/Trusted .npmrc
  participant NpmrcAuth as NpmrcAuth Parser
  participant Config as Config::current

  WorkspaceYAML->>NpmrcAuth: substitute_env_untrusted() (detect ${...})
  alt placeholder in workspace registry
    NpmrcAuth->>Config: drop registry entry + warn
  else no placeholder
    NpmrcAuth->>Config: set registry
  end

  ProjectNpmrc->>NpmrcAuth: from_project_ini(text)
  NpmrcAuth->>NpmrcAuth: detect ${...} in auth/registry
  NpmrcAuth->>Config: omit placeholder-bearing entries + warn

  UserNpmrc->>NpmrcAuth: from_ini(text) (trusted)
  NpmrcAuth->>NpmrcAuth: expand env placeholders
  NpmrcAuth->>Config: apply expanded auth/registry

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~75 minutes

Possibly related issues

• pacquet: port pnpm's layered .npmrc resolution and apply the same load-time credential rescope #11950: Per-source .npmrc parsing and layered loader design directly relate to separating project (untrusted) from trusted user/global config for env-placeholder expansion.

Possibly related PRs

• pnpm/pnpm#11526: Related .npmrc auth/placeholder handling changes in the config reader.
• pnpm/pnpm#11953: Related load-time rescoping and .npmrc parsing pipeline changes touching similar code paths.
• pnpm/pnpm#11730: Related refactors in Config::current and config layering semantics.

Suggested reviewers

• KSXGitHub

Poem

🐰 I sniffed the configs, found braces and dread,
Project secrets hidden, so safely I fled.
Trusted files I munch, expand env with delight,
Workspace stays tidy — no tokens in sight.
Hop secure, hop quick — registries sleep tight!

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

• X
• Mastodon
• Reddit
• LinkedIn

Description

In pacquet, WorkspaceSettings::substitute_env() is now used for trusted sources (global
config.yaml and PNPM_CONFIG_* overlay) but it drops registry/namedRegistries entries
containing ${...} instead of expanding them, causing silent fallback to defaults. This breaks
env-based registry configuration in trusted user/global/env config even though the PR intends to
preserve env expansion for trusted sources.

Code

pacquet/crates/config/src/lib.rs[R1629-1633]

+        let mut global_settings =
       global_config_dir.as_deref().map(WorkspaceSettings::load_global).transpose()?.flatten();
+        if let Some(global_settings) = global_settings.as_mut() {
+            global_settings.substitute_env::<Sys>();
+        }

Evidence

Config::current() calls substitute_env() on global_settings (loaded from user config.yaml)
and on env_settings (built from PNPM_CONFIG_*). But WorkspaceSettings::substitute_env() now
explicitly drops registry when it contains an env placeholder and removes named_registries
entries with placeholders, so trusted configs using ${VAR} are discarded rather than expanded.

pacquet/crates/config/src/lib.rs[1625-1633]
pacquet/crates/config/src/lib.rs[1855-1861]
pacquet/crates/config/src/workspace_yaml.rs[649-676]
pacquet/crates/config/src/env_overlay.rs[71-152]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`WorkspaceSettings::substitute_env()` now filters out env placeholders for `registry` and `namedRegistries` (drops those values). `Config::current()` calls this same method for *trusted* sources (global `config.yaml` and the `PNPM_CONFIG_*` env overlay), which makes trusted registry configuration using `${VAR}` stop working and silently fall back to defaults.
## Issue Context
- Filtering registry URL placeholders is correct for repo-controlled sources (e.g. `pnpm-workspace.yaml`).
- But global `config.yaml` and `PNPM_CONFIG_*` are user-controlled/trusted and should continue to support env expansion (per PR description).
## Fix Focus Areas
- pacquet/crates/config/src/lib.rs[1629-1633]
- pacquet/crates/config/src/lib.rs[1855-1861]
- pacquet/crates/config/src/workspace_yaml.rs[649-676]
- pacquet/crates/config/src/env_overlay.rs[71-152]
## Proposed fix
1. Split substitution into two paths:
- **Trusted substitution** (global config + env overlay): expand `${...}` in `registry` and `named_registries` via `env_replace_lossy` (and keep existing expansion for other scalar fields).
- **Untrusted substitution** (workspace yaml): keep current behavior that drops `registry`/`namedRegistries` entries containing `${...}`.
2. Implement as either:
- `substitute_env_trusted()` and `substitute_env_untrusted()` methods, or
- `substitute_env(opts: SubstituteEnvOptions { trust_registry_urls: bool })`.
3. Update `Config::current()` call sites:
- Use trusted variant for `global_settings` and `env_settings`.
- Use untrusted variant only for `pnpm-workspace.yaml` settings.
4. Add/adjust tests to cover `${VAR}` expansion for `registry`/`namedRegistries` in global `config.yaml` and `PNPM_CONFIG_REGISTRY`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

Project-level .npmrc parsing still allows ${VAR} expansion in *keys* into proxy keys (e.g.,
https-proxy) because isRequestDestinationKey()/is_request_destination_key() does not classify
proxy keys as request-destination keys. This enables ${FOO}=http://proxy/ with FOO=https-proxy
to be accepted, weakening the intended boundary that disallows env expansion for project proxy
destinations.

Code

config/reader/src/loadNpmrcFiles.ts[R233-239]

+function isRequestDestinationKey (key: string): boolean {
+  return isRegistryKey(key) || key.startsWith('//')
+}
+
+function isRequestDestinationValueKey (key: string): boolean {
+  return isRegistryKey(key) || key === 'https-proxy' || key === 'http-proxy' || key === 'proxy'
+}

Evidence

The guard for project .npmrc/project ini performs environment substitution on the key (e.g., via
substituteEnv/env_replace_lossy) and then consults
isRequestDestinationKey()/is_request_destination_key(&key) to decide whether to ignore the entry
when project-source request-destination expansion is disabled; however, that helper only matches
registry/URL-scoped request-destination keys and excludes proxy keys. Because proxy keys are
explicitly accepted later (either via isNpmrcReadableKey() allowing
https-proxy/http-proxy/proxy, or via an explicit match key.as_str() handling proxy keys), a
substituted key that becomes a proxy key is retained and applied, creating a key-expansion bypass
path (notably, even though the value-side guard is_request_destination_value_key() includes proxy
keys, the key-side guard does not).

config/reader/src/loadNpmrcFiles.ts[186-239]
config/reader/src/localConfig.ts[17-24]
config/reader/src/localConfig.ts[189-199]
pacquet/crates/config/src/npmrc_auth.rs[211-280]
pacquet/crates/config/src/npmrc_auth.rs[663-669]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Project-level `.npmrc`/project ini parsing is intended to block env-placeholder expansion for “request destination” entries, but the key-side guard relies on `isRequestDestinationKey()`/`is_request_destination_key()` which omits proxy keys (`https-proxy`, `http-proxy`, `proxy`). As a result, placeholders in *keys* can still expand into proxy keys and be accepted/applied, undermining the intended restriction for project-sourced proxy destinations.
## Issue Context
- The project `.npmrc` guard substitutes env vars in the key (e.g., `substituteEnv(rawKey, ...)` / `env_replace_lossy`) and then checks `isRequestDestinationKey(key)` / `is_request_destination_key(&key)` to decide whether to ignore the entry when project-source request-destination expansion is disabled.
- Proxy keys are still considered readable/handled after this point (e.g., `isNpmrcReadableKey()` explicitly allows proxy keys, and the parser also matches proxy keys explicitly in the main `match key.as_str()`), so a substituted key that becomes `https-proxy`/`http-proxy`/`proxy` will be retained.
- The value-side guard `is_request_destination_value_key()` includes proxy keys, but the key-side destination classification does not, enabling the bypass specifically through key expansion.
## Fix Focus Areas
- config/reader/src/loadNpmrcFiles.ts[233-243]
- config/reader/test/index.ts[693-720]
- pacquet/crates/config/src/npmrc_auth.rs[214-256]
- pacquet/crates/config/src/npmrc_auth.rs[663-669]
- pacquet/crates/config/src/npmrc_auth/tests.rs[241-263]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

Workspace settings still run envReplace() on setting *keys*, so a repo-controlled
pnpm-workspace.yaml can use ${VAR} in a key to synthesize sensitive keys like registry even
though value placeholders are now filtered. This preserves env-driven key expansion in untrusted
workspace settings and undermines the “no placeholder expansion for workspace registry fields”
intent.

Code

config/reader/src/getOptionsFromRootManifest.ts[R72-82]

for (const [key, value] of Object.entries(settings)) {
const newKey = envReplace(key, process.env)
if (typeof value === 'string') {
+      if (newKey === 'registry' && hasEnvPlaceholder(value)) continue
// @ts-expect-error
newSettings[newKey as keyof PnpmSettings] = envReplace(value, process.env)
} else if (newKey === 'registries' || newKey === 'namedRegistries') {
-      // Registry URL maps in workspace yaml must support `${VAR}` substitution
-      // in their values so users can reuse the same env-var pattern they use
-      // in `.npmrc`. Only these keys are treated this way to avoid surprising
-      // behavior on unrelated object-valued settings.
-      newSettings[newKey as keyof PnpmSettings] = replaceEnvInStringValues(value) as never
+      newSettings[newKey as keyof PnpmSettings] = copyStringValuesWithoutEnvPlaceholders(value) as never
} else {
newSettings[newKey as keyof PnpmSettings] = value
}

Evidence

Workspace settings processing unconditionally env-expands keys (envReplace(key, process.env)), and
the workspace manifest is fed through getOptionsFromPnpmSettings(), so key placeholders in
pnpm-workspace.yaml can become real config keys.

config/reader/src/getOptionsFromRootManifest.ts[70-83]
config/reader/src/index.ts[875-887]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`replaceEnvInSettings()` still expands environment placeholders in *keys* for workspace/root manifest settings. That means repository-controlled settings can conditionally produce `registry`/`registries`/`namedRegistries` keys via `${VAR}` in the key name, even though value-side placeholder filtering was added.
## Issue Context
- `getOptionsFromPnpmSettings()` is applied to `workspaceManifest` (from `pnpm-workspace.yaml`) before copying camelCase keys into the effective config.
- Current filtering focuses on placeholder-containing values for `registry` and registry maps; it does not prevent placeholder expansion in keys.
## Fix Focus Areas
- config/reader/src/getOptionsFromRootManifest.ts[70-83]
- config/reader/src/index.ts[875-903]
## Implementation guidance
Option A (minimal):
- If `hasEnvPlaceholder(key)` and the expanded `newKey` is one of `registry`, `registries`, or `namedRegistries`, skip it (and ideally emit a warning so users understand why it was ignored).
Option B (stricter/safer):
- Stop applying `envReplace()` to keys altogether for repo-controlled workspace settings, and only apply env replacement to values for explicitly trusted locations.
Add a regression test:
- A `pnpm-workspace.yaml` (or equivalent settings object in test) with a key like `${FOO}: https://attacker.example/` and `FOO=registry` should not set `config.registry`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

• Stop expanding ${VAR} in repo-controlled registry/proxy URLs and registry credentials.
• Keep env expansion for trusted user/global/auth.ini/CLI config to preserve token workflows.
• Add regression tests in pnpm config reader and pacquet for trust-boundary behavior.

The following are alternative approaches to this PR:

Recommendation: Keep the PR’s trust-boundary approach: treat repository-controlled config as untrusted and filter env placeholders for request destinations and credentials, while preserving expansion for user/global/auth.ini/CLI sources. This balances security (prevents env exfiltration via repo config) with compatibility (existing trusted token workflows continue to work).

getOptionsFromRootManifest.ts Filter env placeholders in workspace registry settings +9/-7

Filter env placeholders in workspace registry settings

• Stops env placeholder expansion for the top-level 'registry' setting and for 'registries'/'namedRegistries' string maps in pnpm settings (e.g., from pnpm-workspace.yaml). Values containing '${...}' are now dropped instead of substituted.

config/reader/src/getOptionsFromRootManifest.ts

---

loadNpmrcFiles.ts Make .npmrc env expansion trust-aware for registry/auth/proxy +70/-6

Make .npmrc env expansion trust-aware for registry/auth/proxy

• Introduces per-source options to disable env expansion for project/workspace '.npmrc' on request destinations (registry, proxies, URL-scoped keys) and auth values. Adds helper key classification and emits targeted warnings when placeholders are ignored.

config/reader/src/loadNpmrcFiles.ts

---

lib.rs Parse project .npmrc with untrusted rules in pacquet +11/-7

Parse project .npmrc with untrusted rules in pacquet

• Splits parsing into trusted vs project sources: project '.npmrc' now uses 'from_project_ini' (no env expansion for request URLs/auth values), while user '.npmrc' and 'auth.ini' remain trusted. Keeps per-source rescoping behavior.

pacquet/crates/config/src/lib.rs

---

npmrc_auth.rs Add trust-aware .npmrc parsing options and warnings +101/-0

Add trust-aware .npmrc parsing options and warnings

• Introduces parse options controlling env expansion for auth values and request destinations, and a dedicated 'from_project_ini' constructor. Blocks placeholder expansion for registry/proxy destinations and auth keys/values in untrusted mode and emits explicit warnings when ignored.

pacquet/crates/config/src/npmrc_auth.rs

---

workspace_yaml.rs Stop env placeholder substitution in workspace registry URLs +13/-12

Stop env placeholder substitution in workspace registry URLs

• Removes env substitution for workspace registry fields and instead drops any 'registry'/'namedRegistries' entries containing '${...}' before applying settings to config. Aligns workspace YAML behavior with upstream trust boundary.

pacquet/crates/config/src/workspace_yaml.rs

---

getOptionsFromRootManifest.test.ts Update workspace settings env-expansion expectations +14/-4

Update workspace settings env-expansion expectations

• Changes tests to assert that '${...}' in 'registries', 'namedRegistries', and 'registry' settings are ignored/dropped rather than expanded. Adds coverage for the 'registry' setting specifically.

config/reader/test/getOptionsFromRootManifest.test.ts

---

index.ts Add regression tests for project vs user .npmrc env expansion +177/-12

Add regression tests for project vs user .npmrc env expansion

• Adds Jest cases ensuring project '.npmrc' does not expand placeholders in registry/scoped registry, URL-scoped keys, auth values, or proxy URLs, and that warnings are produced. Confirms user '.npmrc' may still expand placeholders and adjusts existing auth-placeholder tests to use userconfig.

config/reader/test/index.ts

---

install.rs E2E: env expansion allowed only in trusted user .npmrc +50/-23

E2E: env expansion allowed only in trusted user .npmrc

• Updates the install test to move registry '${VAR}' substitution into a trusted user '.npmrc' provided via '--npmrc-auth-file'. Adds a new test asserting project '.npmrc' registry placeholders are ignored even when the environment is set.

pacquet/crates/cli/tests/install.rs

---

tests.rs Unit tests for trusted vs project .npmrc placeholder handling +113/-0

Unit tests for trusted vs project .npmrc placeholder handling

• Adds tests verifying project '.npmrc' ignores '${VAR}' in registries, URL-scoped keys, auth values, and proxy URLs, while trusted '.npmrc' expands registry placeholders. Ensures filtered placeholders don’t reach derived config/auth headers.

pacquet/crates/config/src/npmrc_auth/tests.rs

---

tests.rs Update workspace YAML tests to assert placeholders are ignored +11/-10

Update workspace YAML tests to assert placeholders are ignored

• Replaces the prior expectation of env substitution in 'namedRegistries' with assertions that workspace registry placeholders are filtered out. Confirms default registry remains unchanged when placeholders are present.

pacquet/crates/config/src/workspace_yaml/tests.rs

---

sharp-registry-env-placeholders.md Document trust-aware env placeholder behavior change +6/-0

Document trust-aware env placeholder behavior change

• Adds a changeset describing that env placeholders are no longer expanded in repo-controlled registry/proxy URLs and credential values. Directs users to move dynamic registry/token setup to trusted config sources.

.changeset/sharp-registry-env-placeholders.md

---

pnpm-lock.yaml Override shell-quote to patched version +5/-4

Override shell-quote to patched version

• Adds an override constraint and updates the lockfile to resolve 'shell-quote' from 1.8.3 to 1.8.4 to avoid the vulnerable version.

pnpm-lock.yaml

---

pnpm-workspace.yaml Add workspace override for shell-quote <1.8.4 +1/-0

Add workspace override for shell-quote <1.8.4

• Adds an overrides entry requiring 'shell-quote' >=1.8.4 for affected dependency ranges, ensuring consumers do not pull the vulnerable version.

pnpm-workspace.yaml

---

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.