pnpm node-linker=pnp with a modulesDir is refused as yarn Plug'n'Play, because the layout detector ignores the modulesDir the crawler honors #1129

[agent] Filed by the scheduled architecture audit routine (ecosystems and formats). Register: register comment.

Kind: bug (one pnpm layout question answered two ways, proven by execution against a real pnpm install). Source: new finding; register E92 (related to E40 and E48).

Problem

"Where does pnpm keep this project's install?" has two answers:

• The npm crawler honors pnpm's modulesDir: modulesDir: in pnpm-workspace.yaml, or modules-dir in .npmrc up to pnpm 10. See pnpm_modules_dirs / pnpm_modules_dir_setting,`` added by Fix pnpm modulesDir store being skipped (#661, #696) #698 for Agent mode ignores pnpm's modulesDir: on pnpm 10.12+ every installed package is "not installed", and apply exits 0 leaving it unpatched #661 and Hosted pnpm vex attests not_affected over an unpatched install when pnpm's modulesDir is set (pnpm 10.12+), because the missed install is treated as "nothing installed" #696.
• The layout detector crawlers/pkg_managers.rs hard-codes node_modules. This affects both detect_npm_pkg_manager step 4 and the pnpm Plug'n'Play carve-out pnpm_pnp_layout_in:``

  (view.is_file("node_modules/.modules.yaml") || view.is_dir("node_modules/.pnpm"))
      && view.is_file("pnpm-lock.yaml")
      && !view.is_file("yarn.lock")

pnpm's node-linker=pnp writes a .pnp.cjs. When modulesDir is also set, the store is <modulesDir>/.pnpm, so the carve-out fails and the tree is classified YarnBerryPnP. Three consumers act on that classification:

• agent apply refuses with yarn_pnp_unsupported and "Use yarn patch <pkg>" (apply.rs#L1332-L1341, and apply --check at #L604-L612);
• the vendored router skips its vendor_pnpm_pnp_unsupported diagnosis and refuses with vendor_yarn_berry_unsupported and the yarn remedy instead (npm_flavor.rs#L181-L210);``
• VEX reads pnpm's .pnp.cjs as a yarn loader (YarnPnpLoader::detect).``

Meanwhile the crawler finds every copy under deps/.pnpm, and agent mode could patch them.

Proof, run twice on e2d9633 with a real pnpm 10.28.0 install: package.json depends on left-pad@1.3.0, .npmrc = node-linker=pnp + modules-dir=deps, then pnpm install. The install wrote .pnp.cjs, deps/.modules.yaml, deps/.pnpm/ and deps/left-pad; node_modules/ holds only .pnpm-workspace-state-v1.json.

Smaller detail: the crawler lists the deps root twice.

Symptoms

None filed. #698 fixed the crawler half (#661, #696), and #859 is the same pattern for yarn's pnpmStoreFolder. This is one more place where the package-manager layout is spelled outside the crawler (E40/#855, E48).

Impact: a pnpm project using its Plug'n'Play linker with a custom modulesDir can't use agent mode, gets the wrong refusal and remedy in vendored mode, and has VEX consult the wrong loader. This combination is uncommon. Plain pnpm with modulesDir only loses the pnpm notice, because detect falls through to Npm/Unknown.

Proposed change

1. Move the modules-dir resolution (pnpm_modules_dir_setting, resolve_modules_folder and the YAML unquote) out of npm_crawler.rs into one pnpm layout helper, for example crawlers/pnpm_layout.rs or formats::pnpm::workspace. Have it answer "the project's pnpm modules dirs" for both a disk root and a ProjectView.
2. detect_npm_pkg_manager step 4 and pnpm_pnp_layout_in look for .modules.yaml / .pnpm under those dirs instead of the literal node_modules.
3. The crawler's pnpm_modules_dirs calls the same helper and deduplicates its roots.
4. Delete the hard-coded node_modules/.modules.yaml / node_modules/.pnpm probes in pkg_managers.rs.

Size and scope

• Files: crawlers/pkg_managers.rs, crawlers/npm_crawler.rs, possibly vendor/lock_inventory/view.rs (a memory-view read of pnpm-workspace.yaml / .npmrc).
• About 100–200 changed lines.
• Out of scope: virtualStoreDir set separately from modulesDir, and yarn's pnpmStoreFolder (Agent mode misses transitive packages in Yarn's pnpm-linker store when pnpmStoreFolder moves it out of node_modules: skipped as package_not_installed, or refused as "first-party source" #859).

Acceptance criteria

• One helper resolves pnpm's modules dirs, used by the crawler and by pkg_managers.
• Regression test: a node-linker=pnp + modulesDir: deps layout (.pnp.cjs, pnpm-lock.yaml, deps/.modules.yaml, deps/.pnpm/) is detected as Pnpm, YarnPnpLoader::detect returns None, and the vendored router returns vendor_pnpm_pnp_unsupported. Cover both the .npmrc and the pnpm-workspace.yaml spelling.
• CLI regression test: apply --json in that layout is not refused with yarn_pnp_unsupported.
• e2e_safety_yarn_pnp, the Yarn 4 node-modules / pnpm-linker projects migrated from Yarn 2 PnP keep a stale .pnp.js, and socket-patch refuses them as Plug'n'Play: agent and vendored exit 1, hosted warns "npm dependencies were NOT scanned" (regression since 3.3.0) #975 stale-loader tests and test_pnpm_modules_dir_is_a_crawl_root stay green.

Dependencies

• Blocked by: nothing.
• Related: Tracking: move vex_consumed's per-ecosystem consumed-copy rules from the CLI into core #855 (per-ecosystem locators in core) and Agent mode misses transitive packages in Yarn's pnpm-linker store when pnpmStoreFolder moves it out of node_modules: skipped as package_not_installed, or refused as "first-party source" #859.

Backlog review — 2026-10-08

Priority: unassigned → P2. Keep the reproduced pnpm PnP/custom-modulesDir layout defect. It blocks agent apply and gives the wrong package-manager diagnosis in a specific supported layout. The report does not demonstrate a successful false attestation; P2 fits the conditional compatibility failure.