Where Plug'n'Play Fits

Plug'n'Play (Yarn Berry and Plug'n'Play) is a fourth answer to the linking step: it skips the folder tree and hands Node.js 2,131 the resolved graph itself. .pnp.cjs records, for every package version, where its files live and which version each of its dependencies resolved to. Yarn 11,798 's pnpapi module lets you query that map directly, and the content-type conflict appears as two plain entries, with no folders involved. Save this script as ~/v5-ch1/pnp-resolve/pnp.js.

pnp.js: reading content-type's resolution from the PnP mapJavaScript

const pnp = require("pnpapi");
for (const [name, ref] of [["express", "npm:5.2.1"], ["body-parser", "npm:2.3.0"]]) {
  const info = pnp.getPackageInformation({ name, reference: ref });
  console.log(`${name}@${ref} -> content-type ${info.packageDependencies.get("content-type")}`);
}

Installing BookNest with Plug'n'Play and querying the mapShell

cd ~/v5-ch1/pnp-resolve && cp ../booknest/package.json .
touch yarn.lock && yarn install >/dev/null     # an empty yarn.lock marks a project root
yarn node pnp.js

Output

express@npm:5.2.1 -> content-type npm:1.0.5
body-parser@npm:2.3.0 -> content-type npm:2.1.0

PnP answers with one lookup what the other layouts answer by walking folders: nothing to hoist, no duplicates (2.1.0 is one zip shared by three dependents), and no phantom dependencies, because a package sees only its own packageDependencies. The price is compatibility: tools that open node_modules paths themselves need Yarn's patches or the node-modules linker (Zero-Installs).

MENU