Deduplication & Hoisting

If [email protected] appears in 50 places in your tree, you don't want 50 copies on disk. Three strategies:

Hoisting (npm v3+, yarn): flatten the tree as much as possible. If two deps want compatible versions of debug, install ONE copy at the top level. Each consumer just uses the same instance.

node_modules/
├── debug/
├── express/
│   └── (no debug here; it's hoisted up)
└── mongoose/
    └── (no debug here either)

Symlinks / hardlinks (pnpm, deno): real install in a content-addressable store; node_modules contains symlinks. Saves disk + lets multiple projects share.

Strict isolation (Yarn 2 PnP, Bazel): no node_modules at all. Loader rewrites require() paths to point into a flat package store.

Hoisting has a danger: phantom dependencies. Code can require('debug') even if debug isn't in your package.json because it ended up in your node_modules. Then a future version of express drops debug and your code breaks mysteriously. pnpm and Yarn PnP both fix this by isolating each package's view.

For this lesson: implement basic deduplication — single copy per (name, version) pair.