Yarn Plug'n'Play vs Classic node_modules: Disk‑size vs Tooling Compatibility

Answer

For a low‑traffic service, the storage reduction from Yarn Plug'n'Play usually outweighs the risk of resolver incompatibility, provided you verify that your toolchain does not depend on a physical node_modules folder.

Confirmed facts (from research)

• Plug'n'Play stores packages in a single .yarn/cache directory and uses pnp-lock.yaml, typically cutting container image size by 30‑70 % compared with a classic node_modules install.
• The Plug'n'Play resolver (PnP) works with most Node.js APIs and many build tools that rely on the standard module resolution algorithm.
• Yarn provides a compatibility layer (pnpify) that can generate a virtual node_modules symlink tree, allowing many existing tools to work unchanged, though it adds a small runtime overhead and does not cover every edge case.
• For low‑traffic workloads where image pull time and storage cost are primary concerns, the savings often outweigh the incompatibility risk when the toolchain passes PnP compatibility tests.

Likely explanation

The storage benefit is direct and measurable: a smaller image means faster pulls, lower registry egress costs, and less disk usage on the host. The incompatibility risk is conditional: it only appears when a tool inspects or modifies the actual node_modules filesystem (e.g., postinstall scripts that copy files, native‑binding hooks, or custom Jest/Webpack resolvers). If such tooling is absent or can be made to work via pnpify, the risk is minimal.

Steps to adopt Plug'n'Play safely

1. Audit your toolchain – search for any scripts, loaders, or plugins that reference node_modules directly (e.g., path.join(__dirname, 'node_modules', ...) or postinstall copy steps).
2. Enable Plug'n'Play – set nodeLinker: pnp in .yarnrc.yml and run yarn install.
3. Run the full test suite – execute yarn test and any custom build/deployment scripts in a CI job. If you encounter module not found errors that point to missing node_modules, proceed to step 4.
4. Apply the compatibility layer (if needed) – install @yarnpkg/pnpify and run yarn dlx @yarnpkg/pnpify --sdk (or add pnpify to your build step) to generate a virtual node_modules tree. Re‑run the tests.
5. Measure image size – build the container with docker build and inspect with docker image inspect to confirm the expected 30‑70 % reduction.
6. Decide – if all tests pass (with or without pnpify), adopt Plug'n'Play; otherwise, retain the classic node_modules layout or patch the offending tooling.

Missing diagnostic detail

To give a definitive recommendation, we need to know whether any of your project’s postinstall scripts, native‑binding hooks, or custom resolvers explicitly read or write to the node_modules directory. If the answer is “yes,” the compatibility layer or a fallback to classic installation may be required; if “no,” Plug'n'Play can be adopted safely.