Feature request: write node_modules/.package-map.json without enabling Node's --experimental-package-map #14937

Background

Since 12.4.1, pnpm writes node_modules/.package-map.json only when nodeExperimentalPackageMap is enabled (changeset skip-unread-package-map: "Nothing reads the file without that setting").

Enabling that setting does more than write the file: pnpm also injects --experimental-package-map=<path> into NODE_OPTIONS for every script it runs (pnpm run, pnpm exec, lifecycle scripts). That changes Node's resolver for all tooling in the workspace, which is a much larger commitment than generating an artifact.

Problem

The map is useful as plain install metadata, independently of Node's resolver. It is the only pnpm-generated artifact that states, for each resolved package key, both the on-disk location and the resolved dependency edges. Tools that need that graph (build systems, task graphs, bundler integrations, vendoring and packaging scripts) can read one JSON file instead of parsing pnpm-lock.yaml and walking symlinks to rediscover the same information.

Today such a tool has two options, and both are bad:

1. Enable nodeExperimentalPackageMap, and accept the experimental Node resolver for every script in the workspace. This is not viable while common tools resolve modules from directories that lie outside any mapped package; Node then throws ERR_PACKAGE_MAP_EXTERNAL_FILE.
2. Reimplement pnpm's resolution on top of the lockfile and the virtual store layout, which duplicates logic pnpm already has and drifts when the layout changes.

Request

A way to opt into writing the file without changing how Node runs. Any of these would work:

• a separate setting, for example packageMap: true or writePackageMap: true;
• an explicit value, for example nodeExperimentalPackageMap: write-only;
• an on-demand command, for example pnpm package-map --out <file>.

Notes

pnpm already generates this file during install when the setting is on, so the request is only to decouple writing the artifact from injecting the Node flag. Keeping the write opt-in is fine; tying it to the resolver flag is what blocks the metadata use case.