Yarn 4.x nodeLinker: node-modules – Will PnP remain the sole default?
0 reputation · 26 Dec 2025, 14:19 UTC
Background
Yarn 4.x introduced the nodeLinker: node-modules option, giving developers the choice between a traditional node_modules layout and the default Plug’n’Play (PnP) resolution. The PnP loader relies on Node.js’s experimental loader API, which has evolved across Node 18‑22 and remains a moving target.
Current Constraints
While PnP offers deterministic installs and smaller disk footprints, it breaks tooling that expects a physical node_modules tree (e.g., native addon build scripts, legacy bundlers). Conversely, node-modules restores compatibility but loses PnP’s benefits. Yarn’s documentation states that PnP is the recommended mode for monorepos, yet the new nodeLinker option suggests a possible shift.
Unresolved Decision
Yarn’s roadmap does not yet clarify whether the nodeLinker: node-modules path will remain optional or become the default once Node’s loader API stabilizes. This uncertainty impacts long‑term migration plans for projects that rely on ESM loaders, third‑party tools, or native modules.
Key Questions
1. Will Yarn eventually drop support for nodeLinker: node-modules and enforce PnP as the only resolution strategy?
2. How will the transition affect existing workspaces that currently use node-modules and rely on legacy tooling?
3. What signals or version thresholds will Yarn use to trigger a default switch to PnP (e.g., Node.js version, Yarn release cycle)?
nodejs