• Create PR with unit tests

Description

lockfileToPackageMap() / dependenciesGraphToPackageMap() build the packages table as a plain
object and assign entries using computed IDs (importerId / path-derived link IDs). If an ID
becomes __proto__ (e.g. project dir or link: target named __proto__), the assignment mutates
the object prototype, corrupting .package-map.json generation and possibly causing downstream
failures when Node uses the map.

Code

lockfile/to-pnp/src/packageMap.ts[R79-96]

+  const packages: PackageMap['packages'] = {}
+  const packageLocationsByModulesDir = isLoose ? new Map<string, Map<string, string>>() : undefined
+  const packageDirsById = isLoose ? new Map<string, string>() : undefined
+
+  const addPackage = (id: string, packageDir: string, dependencies: Map<string, string>) => {
+    packageDirsById?.set(id, packageDir)
+    packages[id] = {
+      url: toRelativeUrl(opts.rootModulesDir, packageDir),
+      dependencies: Object.fromEntries(Array.from(dependencies).sort(([a], [b]) => compareStrings(a, b))),
+    }
+  }
+
+  const addExternalLinkPackage = (target: LinkTarget) => {
+    packages[target.id] ??= {
+      url: toRelativeUrl(opts.rootModulesDir, target.dir),
+      dependencies: {},
+    }
+  }

Evidence

The generator uses a plain object for packages and assigns into it with computed IDs, while
resolveLinkTarget() derives IDs from relative filesystem paths without sanitizing reserved keys;
this can yield __proto__ and trigger prototype mutation. The affected code path is executed during
install when writing node_modules/.package-map.json.

lockfile/to-pnp/src/packageMap.ts[74-103]
lockfile/to-pnp/src/packageMap.ts[333-349]
installing/deps-installer/src/install/index.ts[1656-1667]
installing/deps-restorer/src/index.ts[545-570]

Agent prompt

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

## Issue description
The new package-map generator stores entries in a plain `{}` and writes entries via `packages[id] = ...` and `packages[target.id] ??= ...`. If `id` is `__proto__` (possible from filesystem-derived importer IDs or `link:` target IDs), JS treats it as a special accessor on normal objects and mutates the prototype instead of creating a regular key, corrupting the generated package map.
### Issue Context
This code runs during installs to write `node_modules/.package-map.json`, so a repository/workspace layout (or lockfile `link:` entries) that yields `__proto__` can break package-map generation.
### Fix Focus Areas
- lockfile/to-pnp/src/packageMap.ts[78-103]
- lockfile/to-pnp/src/packageMap.ts[216-229]
### How to fix
- Replace `const packages = {}` with `const packages = Object.create(null) as PackageMap['packages']` (and similarly any other object that may be keyed by attacker-controlled/path-derived IDs).
- Avoid using `??=` on plain objects for such keys unless the container is null-prototype (or switch to `Map<string, PackageMapPackage>` and serialize at the end).
- Ensure any nested objects that might receive computed keys are also null-prototype if applicable.

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

Description

parseYarn2Yaml() loads attacker-controlled yarn.lock YAML into a plain object and
parseYarn2Lock() iterates it with for..in while assigning into a plain {} map, which allows
__proto__/prototype-chain tricks to inject inherited enumerable keys and/or prototype-pollute
dependencies during pnpm import. This can lead to unexpected dependency entries or crashes/DoS
when importing a malicious repository.

Code

installing/commands/src/import/index.ts[R243-253]

+function parseYarn2Yaml (lockFileContents: string): YarnLockYaml {
+  const parseYarnLock = yaml.load(lockFileContents, {
+    schema: yaml.FAILSAFE_SCHEMA,
+    json: true,
+  })
+  if (parseYarnLock == null) return {}
+  if (typeof parseYarnLock !== 'object' || Array.isArray(parseYarnLock)) {
+    throw new PnpmError('YARN_LOCKFILE_PARSE_FAILED', `Expected an indexed object, got a ${Array.isArray(parseYarnLock) ? 'array' : typeof parseYarnLock} instead. Does your file follow Yaml's rules?`)
+  }
+  return parseYarnLock as YarnLockYaml
+}

Evidence

The new YAML parsing returns a plain object from yaml.load(), and the existing loop uses for..in
(which can enumerate inherited enumerable properties) while writing into a plain {} map (which is
vulnerable to __proto__ key assignment semantics).

installing/commands/src/import/index.ts[219-236]
installing/commands/src/import/index.ts[243-253]

Agent prompt

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

## Issue description
`parseYarn2Yaml()` uses `js-yaml` to load untrusted YAML into a normal JS object, and `parseYarn2Lock()` then uses `for..in` and writes into a plain `{}`. A crafted `yarn.lock` can exploit `__proto__`-style prototype pollution to introduce inherited enumerable keys into the iteration and/or mutate the prototype of the destination map.
### Issue Context
This is on the `pnpm import` path, where the repository’s `yarn.lock` should be treated as attacker-controlled input.
### Fix Focus Areas
- installing/commands/src/import/index.ts[219-253]
### Suggested fix approach
- Avoid `for..in` over the parsed YAML object; iterate only own keys via `Object.keys()` / `Object.entries()`.
- Build the output map with a null prototype to prevent `__proto__` assignment from mutating prototypes:
- `const dependencies = Object.create(null) as YarnPackageLock`
- After `yaml.load`, defensively copy only own enumerable properties into a null-prototype object (or otherwise ensure the returned structure is not prototype-pollutable) before further processing.
- Optionally, reject/ignore dangerous keys like `__proto__`, `prototype`, and `constructor` explicitly when copying/iterating.

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

Description

makeNodePackageMapOption()/make_node_package_map_option() only quotes the package-map path when
whitespace is present, so paths containing quotes can be misparsed by Node’s NODE_OPTIONS
tokenizer, potentially altering/breaking the intended flags when node-experimental-package-map is
enabled under exec/run flows.

Code

exec/lifecycle/src/index.ts[R12-20]

+export function makeNodePackageMapOption (packageMapPath: string, env?: Record<string, string | undefined>): { NODE_OPTIONS: string } {
+  let { NODE_OPTIONS } = env ?? process.env
+  NODE_OPTIONS = `${removeNodePackageMapOption(NODE_OPTIONS ?? process.env.NODE_OPTIONS ?? '')} --experimental-package-map=${quotePathIfNeeded(packageMapPath)}`.trim()
+  return { NODE_OPTIONS }
+}
+
+function quotePathIfNeeded (path: string): string {
+  return /\s/.test(path) ? JSON.stringify(path) : path
+}

Evidence

The implementations in both TS and Rust use a quoting helper (quotePathIfNeeded() /
quote_path_if_needed()) that returns the raw path string unless whitespace exists, and the
formatted --experimental-package-map= value is then directly concatenated into a reconstructed
NODE_OPTIONS string. Because the path is sourced from the filesystem (e.g., via existsInDir()
and workspace/project directory + node_modules/.package-map.json) and forwarded unmodified into
the option builder, any embedded quotes in the path can affect how Node tokenizes NODE_OPTIONS,
leading to unexpected argument boundaries or malformed quoting.

exec/lifecycle/src/index.ts[12-20]
exec/commands/src/run.ts[291-307]
pacquet/crates/package-manager/src/package_map.rs[362-370]
pacquet/crates/package-manager/src/package_map.rs[802-808]

Agent prompt

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

## Issue description
`makeNodePackageMapOption()` (TS) and `make_node_package_map_option()` (Rust) build `NODE_OPTIONS` by string concatenation and only quote `packageMapPath` when it contains whitespace. If the path contains quotes (valid on POSIX), Node’s parsing of `NODE_OPTIONS` may treat the value as multiple arguments or malformed quoting, potentially changing effective runtime flags or failing Node startup.
## Issue Context
The package map path is derived from the filesystem (workspace/project directory + `node_modules/.package-map.json`, e.g. via `existsInDir()`) and is forwarded into `NODE_OPTIONS` for `pnpm run/exec` and pacquet CLI execution flows when `node_experimental_package_map` is enabled and `NODE_OPTIONS` is reconstructed from config/environment.
## Fix Focus Areas
- exec/lifecycle/src/index.ts[12-20]
- pacquet/crates/package-manager/src/package_map.rs[362-370]
- pacquet/crates/package-manager/src/package_map.rs[802-808]

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

Description

writePackageMap() / writePackageMapFromDependenciesGraph() persist .package-map.json via
fs.writeFile, so an interrupted install or concurrent reader can observe truncated/invalid JSON
and break Node startup when --experimental-package-map is used. This is inconsistent with pnpm’s
existing practice of atomic writes for on-disk contracts (e.g. lockfiles).

Code

lockfile/to-pnp/src/packageMap.ts[R58-78]

+export async function writePackageMap (
+  lockfile: LockfileObject,
+  opts: PackageMapOptions
+): Promise<void> {
+  await fs.mkdir(opts.rootModulesDir, { recursive: true })
+  await fs.writeFile(
+    path.join(opts.rootModulesDir, PACKAGE_MAP_FILENAME),
+    `${JSON.stringify(lockfileToPackageMap(lockfile, opts), null, 2)}\n`,
+    'utf8'
+  )
+}
+
+export async function writePackageMapFromDependenciesGraph (
+  opts: DependenciesGraphPackageMapOptions
+): Promise<void> {
+  await fs.mkdir(opts.rootModulesDir, { recursive: true })
+  await fs.writeFile(
+    path.join(opts.rootModulesDir, PACKAGE_MAP_FILENAME),
+    `${JSON.stringify(dependenciesGraphToPackageMap(opts), null, 2)}\n`,
+    'utf8'
+  )

Evidence

The new package map writer uses a direct write to the final path, while existing lockfile writers in
this repo use atomic-write helpers to avoid torn/corrupt files on disk.

lockfile/to-pnp/src/packageMap.ts[58-78]
lockfile/fs/src/write.ts[58-83]

Agent prompt

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

## Issue description
`lockfile/to-pnp/src/packageMap.ts` writes `.package-map.json` using `fs.writeFile(...)`, which can leave a partially-written JSON file if the process is interrupted or if another process reads while the write is in progress.
### Issue Context
The repo already treats key on-disk outputs as atomic-write-only (e.g. lockfile writers use `write-file-atomic`), which avoids torn reads and corrupted state.
### Fix Focus Areas
- Use an atomic temp-file + rename write for `.package-map.json` (likely `write-file-atomic`, already used elsewhere).
- Keep the output bytes identical (including trailing `\n`) to avoid churn.
- lockfile/to-pnp/src/packageMap.ts[58-79]
- lockfile/fs/src/write.ts[58-83]

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

Description

The installers always materialize locationByDepPath by iterating the whole dependency graph even
though package-map generation can derive package locations from depPath for the normal local virtual
store case. This adds avoidable extra CPU and allocations on the install hot path when
enableGlobalVirtualStore is not used.

Code

installing/deps-installer/src/install/index.ts[R1736-1741]

+      await writePackageMap(result.currentLockfile, {
+        importerNames,
+        lockfileDir: ctx.lockfileDir,
+        locationByDepPath: Object.fromEntries(
+          Object.values(dependenciesGraph).map((node) => [node.depPath, node.dir])
+        ),

Evidence

PackageMapOptions.locationByDepPath is documented as needed only for the global virtual store and
the writer explicitly falls back when it’s missing, yet deps-installer always builds the full map
from the dependencies graph before calling writePackageMap(). This makes the extra
traversal/object creation avoidable in the local virtual store case.

lockfile/to-pnp/src/packageMap.ts[24-38]
lockfile/to-pnp/src/packageMap.ts[138-145]
installing/deps-installer/src/install/index.ts[1732-1746]

Agent prompt

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

## Issue description
`locationByDepPath` is always computed via `Object.fromEntries(Object.values(dependenciesGraph)...`, which is a full traversal + allocation of a large object. The package-map writer already falls back to the standard `<virtualStoreDir>/<depPathToFilename>/node_modules/<name>` layout when `locationByDepPath` is absent.
## Issue Context
`locationByDepPath` is documented as required only for the global virtual store (content-hashed locations). For the common local virtual store, passing it is redundant.
## Fix Focus Areas
- installing/deps-installer/src/install/index.ts[1732-1746]
- lockfile/to-pnp/src/packageMap.ts[24-38]
- lockfile/to-pnp/src/packageMap.ts[138-145]

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

Description

resolveLinkTarget() selects POSIX vs Win32 path handling using the full ref string (which includes
the link: prefix), so Windows-absolute refs like link:C:\... won’t be detected as Win32 on POSIX
and are treated as relative paths. This can generate incorrect package-map IDs/URLs for such link
targets, breaking package-map resolution for cross-platform lockfiles that contain Windows-absolute
link: entries.

Code

lockfile/to-pnp/src/packageMap.ts[R342-348]

+function resolveLinkTarget (lockfileDir: string, importerId: string | undefined, ref: string): LinkTarget {
+  const pathUtils = getPathUtils(lockfileDir, ref)
+  const importerDir = pathUtils.resolve(lockfileDir, importerId ?? '.')
+  const linkPath = ref.slice(5)
+  const dir = pathUtils.isAbsolute(linkPath)
+    ? linkPath
+    : pathUtils.resolve(importerDir, linkPath)

Evidence

The code selects the path implementation using ref (which includes the link: prefix), but
Windows-absolute detection is anchored to the beginning of the string; therefore link:C:\... will
not be classified as Windows-absolute, and path.posix.isAbsolute('C:\...') will return false,
causing the Windows absolute to be resolved as a relative path.

lockfile/to-pnp/src/packageMap.ts[342-353]
lockfile/to-pnp/src/packageMap.ts[433-456]

Agent prompt

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

## Issue description
`resolveLinkTarget()` calls `getPathUtils(lockfileDir, ref)` before stripping the `link:` prefix. On POSIX, a Windows-absolute `link:` ref like `link:C:\foo` will not match the Windows-absolute regexp (because it doesn’t start with a drive letter due to the `link:` prefix), so the code will use POSIX path semantics and incorrectly treat `C:\foo` as a relative path.
## Issue Context
This logic lives in the newly added package-map writer and affects how `link:` dependency targets are resolved into (id, dir) pairs.
## Fix Focus Areas
- lockfile/to-pnp/src/packageMap.ts[342-356]
- lockfile/to-pnp/src/packageMap.ts[433-456]
## Suggested fix
- In `resolveLinkTarget()`, compute `linkPath = ref.slice(5)` first.
- Call `getPathUtils(lockfileDir, linkPath)` (or include `importerDir` + `linkPath`) instead of passing the raw `ref`.
- Then use the returned `pathUtils` to evaluate `isAbsolute(linkPath)` and to resolve the path.

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

Description

pacquet’s split_node_options() and the related removal logic do not correctly honor
backslash-escaped quotes, treating any " inside a quoted NODE_OPTIONS token as a real quote
terminator. This can cause remove_node_package_map_option()/removeNodePackageMapOption() to fail
to fully strip an existing --experimental-package-map flag and lead
make_node_package_map_option()/makeNodePackageMapOption() to emit malformed NODE_OPTIONS,
potentially breaking exec/run/lifecycle script execution and idempotent rebuilds.

Code

pacquet/crates/package-manager/src/package_map.rs[R777-804]

+fn split_node_options(node_options: &str) -> Vec<String> {
+    let mut tokens = Vec::new();
+    let mut token = String::new();
+    let mut quote: Option<char> = None;
+    for ch in node_options.chars() {
+        if let Some(q) = quote {
+            token.push(ch);
+            if ch == q {
+                quote = None;
+            }
+            continue;
+        }
+        if ch == '"' || ch == '\'' {
+            quote = Some(ch);
+            token.push(ch);
+        } else if ch.is_whitespace() {
+            if !token.is_empty() {
+                tokens.push(std::mem::take(&mut token));
+            }
+        } else {
+            token.push(ch);
+        }
+    }
+    if !token.is_empty() {
+        tokens.push(token);
+    }
+    tokens
+}

Evidence

quote_path_if_needed() can emit escaped quotes (\") when a path contains ", but
split_node_options() has no escape-handling logic and will mis-tokenize by terminating a quoted
token at the escaped quote, which directly undermines remove_node_package_map_option() and
corrupts the final NODE_OPTIONS output. Separately, the code notes that Node treats backslash as
an escape, yet the regex approach for removal uses a fragment like "[^"]*", which necessarily
stops at an escaped quote and therefore cannot reliably match/remove the entire quoted
--experimental-package-map token, leaving trailing remnants that get concatenated with the newly
generated flag.

pacquet/crates/package-manager/src/package_map.rs[756-818]
exec/lifecycle/src/index.ts[12-33]

Agent prompt

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

## Issue description
`NODE_OPTIONS` manipulation is not robust when quoted tokens contain backslash-escaped quotes (e.g. `\"`): the tokenizer/removal logic can terminate tokens early, fail to fully remove an existing `--experimental-package-map` option, and then produce malformed `NODE_OPTIONS` when appending the new option.
## Issue Context
- `quote_path_if_needed()` can legitimately produce `\"` sequences inside a quoted `--experimental-package-map=...` token, so the tokenization/removal logic must correctly round-trip such values.
- The codebase documents that Node’s `NODE_OPTIONS` parsing treats `\` as an escape character; however, current logic either lacks escape handling during tokenization (`split_node_options()`) or uses a regex pattern that cannot span escaped quotes, making removal unreliable and potentially breaking exec/run/lifecycle scripts when `NODE_OPTIONS` includes such tokens or when rebuilding it idempotently.
## Fix Focus Areas
- pacquet/crates/package-manager/src/package_map.rs[756-818]
- exec/lifecycle/src/index.ts[28-32]

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

Description

pnpm exec injects --experimental-package-map only when node_modules/.package-map.json exists,
but installs write the map to ctx.rootModulesDir, which is derived from the configurable
modulesDir option. With modulesDir != node_modules, the map is generated but the flag won’t be
injected, so the feature silently doesn’t work for exec/run flows.

Code

exec/commands/src/exec.ts[R226-227]

+  const existsPackageMap = existsInDir.bind(null, path.join('node_modules', '.package-map.json'))
+  const workspacePackageMapPath = opts.nodeExperimentalPackageMap && opts.workspaceDir && existsPackageMap(opts.workspaceDir)

Evidence

exec.ts looks for node_modules/.package-map.json, while the install pipeline writes to
ctx.rootModulesDir, and ctx.rootModulesDir is computed from opts.modulesDir (not always
node_modules). Therefore, when modulesDir differs, the runtime injection can’t find the
generated map.

exec/commands/src/exec.ts[223-227]
installing/read-projects-context/src/index.ts[49-55]
installing/deps-installer/src/install/index.ts[1656-1667]

Agent prompt

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

## Issue description
`exec/commands` hard-codes `node_modules/.package-map.json` when deciding whether to inject `--experimental-package-map`, but the installer writes `.package-map.json` to `rootModulesDir` computed from the configurable `modulesDir` option.
### Issue Context
This creates a layout mismatch: when users configure `modulesDir` to a non-default location (relative or absolute), pnpm will write the package map there, but exec/run won’t find it and won’t inject the flag.
### Fix Focus Areas
- exec/commands/src/exec.ts[226-253]
- exec/commands/src/run.ts[282-307]
- exec/commands/src/runRecursive.ts[76-151]

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

Description

Pacquet writes node_modules/.package-map.json for isolated installs regardless of
config.node_experimental_package_map, even though the config is documented as opt-in. This
violates the documented contract and adds unnecessary package-map generation work and file writes on
the install hot path when the feature is disabled.

Code

pacquet/crates/package-manager/src/install.rs[R2129-2131]

+fn should_write_package_map(_config: &Config, node_linker: NodeLinker) -> bool {
+    node_linker == NodeLinker::Isolated
+}

Evidence

The pacquet config documents node_experimental_package_map as the gate for writing
.package-map.json, but the actual gate function ignores the config and only checks
NodeLinker::Isolated, and the install flow calls it before writing.

pacquet/crates/config/src/lib.rs[436-440]
pacquet/crates/package-manager/src/install.rs[1339-1355]
pacquet/crates/package-manager/src/install.rs[2129-2131]

Agent prompt

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

## Issue description
`should_write_package_map` ignores `config.node_experimental_package_map` and returns `true` for every isolated install, causing `.package-map.json` to be written even when the feature is configured off.
### Issue Context
`Config` explicitly documents `node_experimental_package_map` as controlling whether the file is written. The install path currently contradicts that documentation.
### Fix Focus Areas
- pacquet/crates/package-manager/src/install.rs[1339-1355]
- pacquet/crates/package-manager/src/install.rs[2129-2131]
- pacquet/crates/config/src/lib.rs[436-444]

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

Description

Package-map writers generate .package-map.json with pretty-printed JSON (e.g.,
JSON.stringify(..., null, 2) / serde_json::to_vec_pretty), adding avoidable CPU, allocations,
and larger output on pnpm/pacquet’s install hot path when package maps are materialized. This extra
work scales with package-map/lockfile size and is exercised during normal install flows
(deps-installer and headless deps-restorer).

Code

lockfile/to-pnp/src/packageMap.ts[R51-71]

+export async function writePackageMap (
+  lockfile: LockfileObject,
+  opts: PackageMapOptions
+): Promise<void> {
+  await fs.mkdir(opts.rootModulesDir, { recursive: true })
+  await fs.writeFile(
+    path.join(opts.rootModulesDir, PACKAGE_MAP_FILENAME),
+    `${JSON.stringify(lockfileToPackageMap(lockfile, opts), null, 2)}\n`,
+    'utf8'
+  )
+}
+
+export async function writePackageMapFromDependenciesGraph (
+  opts: DependenciesGraphPackageMapOptions
+): Promise<void> {
+  await fs.mkdir(opts.rootModulesDir, { recursive: true })
+  await fs.writeFile(
+    path.join(opts.rootModulesDir, PACKAGE_MAP_FILENAME),
+    `${JSON.stringify(dependenciesGraphToPackageMap(opts), null, 2)}\n`,
+    'utf8'
+  )

Evidence

The cited writer implementations explicitly use pretty serialization—TypeScript via
JSON.stringify(..., null, 2) in writePackageMap() / writePackageMapFromDependenciesGraph() and
Rust via serde_json::to_vec_pretty in write_package_map() / write_hoisted_package_map()—which
necessarily performs extra formatting work and produces larger JSON than compact output. The call
sites in the install pipeline (deps-installer and deps-restorer) show these writers are invoked as
part of standard installs, meaning the formatting overhead is on the critical path and repeats
proportionally to the size of the generated package map.

lockfile/to-pnp/src/packageMap.ts[51-71]
installing/deps-installer/src/install/index.ts[1637-1649]
installing/deps-restorer/src/index.ts[545-571]
pacquet/crates/package-manager/src/package_map.rs[52-76]
pacquet/crates/package-manager/src/install.rs[1235-1258]
pacquet/crates/package-manager/src/install_frozen_lockfile.rs[961-980]

Agent prompt

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

## Issue description
The package-map writers are currently emitting `.package-map.json` using pretty-printed JSON (`JSON.stringify(..., null, 2)` / `serde_json::to_vec_pretty`), which adds avoidable formatting CPU, extra allocations, and larger output during installs.
## Issue Context
These package maps are generated/materialized as part of standard install flows (including deps-installer and headless deps-restorer), so the pretty-printing overhead sits on a performance-sensitive install hot path and scales with the size of the package map/lockfile.
## Fix Focus Areas
- lockfile/to-pnp/src/packageMap.ts[51-71]
- installing/deps-installer/src/install/index.ts[1637-1649]
- installing/deps-restorer/src/index.ts[545-571]
- pacquet/crates/package-manager/src/package_map.rs[52-76]

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

Description

The non-headless installer only writes .package-map.json for nodeLinker=isolated, while the
headless installer writes it for hoisted too, so hoisted installs may or may not produce the map
depending on which install codepath runs.

Code

installing/deps-installer/src/install/index.ts[R1593-1594]

+  const shouldWritePackageMap = opts.enableModulesDir !== false && opts.nodeLinker === 'isolated' && !opts.virtualStoreOnly
if (!opts.lockfileOnly && !isInstallationOnlyForLockfileCheck && opts.enableModulesDir) {

Evidence

The deps-installer path gates writing to isolated only, while deps-restorer headless writes a
hoisted map via writePackageMapFromDependenciesGraph, creating divergent outputs for the same
nodeLinker=hoisted configuration.

installing/deps-installer/src/install/index.ts[1591-1649]
installing/deps-restorer/src/index.ts[545-570]

Agent prompt

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

## Issue description
Package-map generation differs across install implementations:
- `deps-installer` writes only when `opts.nodeLinker === 'isolated'`.
- `deps-restorer` headless path writes for `hoisted` as well.
This makes `.package-map.json` output non-deterministic for hoisted installs depending on whether pnpm takes the headless path, and can make `node-experimental-package-map` appear to “randomly” not work (exec/run code checks for file existence before injecting the flag).
### Issue Context
The PR description states pnpm will always generate `node_modules/.package-map.json`; the current implementation effectively makes this conditional for hoisted installs.
### Fix Focus Areas
- installing/deps-installer/src/install/index.ts[1593-1649]
- installing/deps-restorer/src/index.ts[545-570]
### Suggested fix
- Either:
1) Implement package-map generation for `nodeLinker=hoisted` in the non-headless path too (likely via a dependencies-graph-based writer, similar to headless), or
2) Explicitly scope/adjust behavior so both paths match (and update docs/notes accordingly).
- Add a test that asserts `.package-map.json` existence for hoisted installs across both headless and non-headless scenarios (or clearly asserts the intended behavior).

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

• ➕ Avoids extra filesystem writes for users not experimenting with the feature
• ➕ Reduces surface area for unexpected diffs in tooling that watches node_modules
• ➖ Harder for third-party tooling to discover/experiment without opting in
• ➖ Requires more branching in install paths and tests

• ➕ No install-time overhead; explicit user intent
• ➕ Easier to iterate on format without tying to every install
• ➖ Map can go stale relative to node_modules unless re-generated
• ➖ Less seamless for lifecycle scripts that need the map immediately after install

• ➕ Keeps generated artifacts colocated with virtual store state
• ➕ May reduce redundant writes in some workflows
• ➖ More complex cross-platform handling (symlinks, permissions)
• ➖ Harder for tools expecting a stable root location