A bundle report for a production build shows the same package — say date-fns — appearing twice under two different node_modules paths at two different versions. Why does the bundler emit both copies, and how do you get down to one?

## What a duplicate in the report means A bundler does not resolve imports by package name; it resolves them to **absolute file paths**. If one import lands on `node_modules/date-fns/format.js` and another on `node_modules/some-lib/node_modules/date-fns/format.js`, those are two unrelated modules as far as the build is concerned, and both are included. The treemap is simply reporting the truth of the module graph. The cause is the install tree. Package managers must satisfy every declared range. When your app depends on `date-fns@^3` and a chart library depends on `date-fns@^2`, no single installed version satisfies both, so the manager hoists one to the top level and nests the other under the dependent that needs it. Nothing is broken — the app works — you are just shipping the library twice. ```bash # Who pulled in each copy? npm ls date-fns # prints every dependent and the version it resolved to # or, depending on the manager yarn why date-fns pnpm why date-fns ``` ## Why it costs more than bytes The obvious cost is payload: two copies of a 40 kB library is 40 kB of pure waste, and it comes with matching parse and compile time. There are two subtler costs. First, **module identity breaks**. Anything that relies on a single shared instance across the app stops working when there are two: a class whose instances are checked with `instanceof`, a plugin registry, a module-level singleton cache, a context or store object. Code that looks correct fails with confusing symptoms because object A came from copy 1 and the check lives in copy 2. Some libraries guard against this by warning at runtime when they detect multiple instances. Second, **the duplicate hides**. It rarely appears as a bug report. It shows up as a bundle that is quietly larger than anyone expects, which is exactly why looking for repeated package names is a standard step when you read a bundle report. ## Working the fix, in order of preference **1. Align the ranges honestly.** Look at the dependency chain the manager printed. Usually one dependent is behind. Upgrading it so its range overlaps yours collapses both copies into one, and it is the only fix that leaves the tree truthful. Sometimes the reverse is true — you are on a new major that nothing else supports yet, and moving your own range down is the cheaper move. **2. Let the manager deduplicate.** If the ranges *do* overlap but the tree was built badly across incremental installs, `npm dedupe` (or reinstalling from a clean lockfile) can flatten it. This only works when a single version genuinely satisfies everyone; it will not resolve a real conflict. **3. Force a single version.** Every manager has an escape hatch: npm's `overrides` field (available from npm 8.3), Yarn's `resolutions`, pnpm's `overrides`. These rewrite what a dependent gets regardless of what it asked for. ```json { "overrides": { "date-fns": "^3.0.0" } } ``` This is a real intervention, not a formality. You have told a package to run against a version it never declared support for. If the majors differ, the API may have changed underneath it. Use it when the version gap is small or the surface used is narrow, pin the override explicitly, and make sure the affected paths are covered by tests. Leave a comment saying why the override exists — the next person will otherwise delete it. ## The singleton case For libraries where two copies are semantically wrong rather than merely wasteful, the ecosystem convention is a **peer dependency**: the library declares that its host must provide the package, rather than depending on it directly. That converts a silent duplication into an install-time warning or error, which is the point. When you publish a package that plugs into a framework or a state library, declaring it as a peer dependency is what prevents your consumers from finding two copies in their bundle report. ## Not every duplicate is a mistake Before you spend a day on it, check the weight and the chunk. Two copies of a 3 kB utility inside a rarely loaded chunk is not worth a risky override. And be careful reading paths: monorepo workspaces and pnpm's symlinked store can make one physical copy appear under several paths in a report. Confirm with the manager's own dependency query before concluding you have two.