How to Find Duplicate Dependencies in a Monorepo Bundle

This walkthrough extends Webpack Bundle Analysis Techniques inside JavaScript Bundle Optimization & Code Splitting. The bundle report shows date-fns three times, @internal/ui twice, and a suspiciously large vendor chunk. In a workspace repository this is normal and it is not a bundler bug: two packages asked for incompatible ranges of the same dependency, the package manager installed both, and the bundler faithfully included each one.

Duplicates cost bytes, parse time, and correctness — two copies of a state library mean two independent stores.

Rapid Diagnosis: Confirm and Quantify

• Read the analyzer treemap for repeated names. The same package name appearing under two different paths is the signal; the nesting tells you who pulled each copy.
• Ask the package manager first. npm ls <pkg> or pnpm why <pkg> shows the resolution tree and the requested ranges — the actual cause.
• Separate real duplicates from re-exports. A package appearing twice with different sizes is usually two versions; identical sizes under different paths can be a symlink or an alias artefact.
• Check for singleton violations. React, state stores and context providers must be single instances. A duplicate here causes bugs, not just bytes: hooks fail, contexts read as undefined.

Root Cause Analysis

1. Incompatible semver ranges across workspace packages. One package pins ^1.9 while another requires ^2.3. The package manager cannot satisfy both with one install, so it nests a second copy — correct behaviour, expensive outcome.

2. A dependency that should have been a peer. A shared library declared as a regular dependency inside an internal package gets its own copy per consumer. Declaring it as a peer dependency instead makes the consumer supply the single instance.

3. Mixed module formats. The same package resolved once as ESM and once as CommonJS produces two distinct modules in the graph even at the same version — the mechanism behind dual package hazard.

4. Aliases and symlinks that bypass resolution. A build alias pointing at a source path while another import resolves through node_modules yields two module identities for what is, on disk, the same code.

Step-by-Step Resolution

1. Get the authoritative list of duplicates from the package manager.

# Every package installed at more than one version, with who asked for what.
npm ls --all --json 2>/dev/null \
  | jq -r '[paths(objects) as $p | {name: ($p[-1]), v: (getpath($p).version)}]
           | map(select(.v)) | group_by(.name) | map(select((map(.v)|unique|length) > 1))
           | .[][0].name' | sort -u
# trade-off: this lists what is INSTALLED, which is a superset of what is
# BUNDLED — dev-only duplicates are noise here. Cross-check against the bundle
# report before acting on any entry.

Expected outcome: a short list of genuinely duplicated packages with their requesters.

2. Align the ranges at the source. The durable fix is agreeing on one range across the workspace, not overriding it downstream.

{
  "pnpm": { "overrides": { "date-fns": "^3.6.0" } },
  "resolutions": { "date-fns": "^3.6.0" }
}

# Then align the packages that were asking for the old range.
pnpm -r update date-fns@^3.6.0
# trade-off: an override forces a version a package did not declare support for.
# It usually works and occasionally breaks at runtime in a way no type check
# catches — run the affected packages' test suites before shipping it.

Expected outcome: one install, one copy in the bundle, and the byte saving equal to the smaller copies.

3. Make shared libraries peer dependencies. Inside internal packages, anything that must be a singleton belongs in peerDependencies.

{
  "name": "@internal/ui",
  "peerDependencies": { "react": "^18 || ^19", "@internal/store": "workspace:*" },
  "devDependencies": { "react": "^19.0.0" }
}

Expected outcome: consumers supply the single instance; the internal package can never bundle its own.

4. Enforce single instances in the bundler as a backstop. Resolution aliases catch anything the dependency graph still splits.

// webpack: one physical path per singleton, whatever the graph says.
const path = require('node:path');
module.exports = {
  resolve: {
    alias: {
      react: path.resolve(__dirname, 'node_modules/react'),
      'react-dom': path.resolve(__dirname, 'node_modules/react-dom')
    },
    dedupe: ['@internal/store']         // Vite exposes the same idea directly
  }
};
// trade-off: an alias silently forces one version on code that expected
// another. It is a backstop for singletons, not a substitute for fixing the
// ranges — and it hides the real problem from the next person who looks.

Verification

Re-run the analyzer and confirm each previously duplicated package appears exactly once. Compare the vendor chunk's size before and after; the saving should match the sum of the removed copies, and if it does not, one copy is still being pulled through a different path.

For singletons, verify identity at runtime rather than trusting the graph:

// Two copies produce two different module identities.
import * as store from '@internal/store';
window.__storeInstances ??= new Set();
window.__storeInstances.add(store);
console.assert(window.__storeInstances.size === 1, 'duplicate store instance!');

Then keep it from returning. Duplicates reappear whenever someone adds a dependency, so add a CI check that fails the build when a package resolves to more than one version, and pair it with the bundle-size budget described in reducing vendor chunk size in a React app.

FAQ

Related

• Webpack Bundle Analysis Techniques — reading the report that surfaces these duplicates.
• Reducing vendor chunk size in a React app — what to do with the chunk once duplicates are gone.
• Fixing dual package hazard in a library — the module-format cause of same-version duplication.