Duplicate Dependency Detection - Missing Parent Package Tracking

[dreyfus92]

After battle testing the cli with storybook's monorepo, I found that we need to improve the duplicate deps detection.

This affects users while debugging dependency issues, especially in monorepos.

Many duplicate dependencies show "via the following 0 package(s)" instead of listing the actual parent packages that depend on them. This makes it difficult for users to understand which packages are causing duplicate dependencies and how to resolve them.

When running e18e analyze on projects (especially monorepos), duplicate dependency messages often show zero parent packages:

❌ Broken Example:

[duplicate dependency] @angular-devkit/build-angular has 2 installed versions:
│      via the following 0 package(s)
│      19.2.19 via the following 0 package(s)

✅ Working Example (for reference):

Some dependencies do show parents correctly:

[duplicate dependency] jsonc-parser has 2 installed versions:
│      3.3.1 via the following 0 package(s)
│      3.2.0 via the following 1 package(s) nx@22.1.3

[duplicate dependency] tslib has 3 installed versions:
│      2.8.1 via the following 0 package(s)
│      via the following 8 package(s) @nx/devkit@22.1.3, @emnapi/wasi-threads@1.1.0, ...

All duplicate dependencies should show their parent packages (the packages that directly depend on them), even when:

• Dependencies are hoisted to the root node_modules
• Dependencies appear in the lockfile but aren't directly referenced in a package.json
• Dependencies are nested deep in the dependency tree
• Dependencies are root-level dependencies

Expected Output:

[duplicate dependency] @angular-devkit/build-angular has 2 installed versions:
│      19.2.18 via the following 2 package(s) @storybook/angular@8.0.0, @storybook/builder-webpack5@8.0.0
│      19.2.19 via the following 1 package(s) @storybook/core-server@8.0.0

The root cause is that computeParents function in src/analyze/duplicate-dependencies.ts uses lockparse's traverse function to walk the dependency tree, but there are several issues:

Issue 1: Early Return Condition

Location: src/analyze/duplicate-dependencies.ts:76

const visitorFn: VisitorFn = (node, parent, _path) => {
  if (!duplicateDependencies.has(node.name) || !parent) {
    return;  // ❌ Skips nodes without parent or not in map
  }
  // ... rest of logic
};

Problem: This condition causes the function to skip nodes that:

• ❌ Are not in the duplicateDependencies map (but should be tracked)
• ❌ Don't have a parent (root-level dependencies)

Issue 2: Traversal Limitations

The lockparse traverse function may not capture all parent relationships correctly, especially for:

Scenario	Impact
Hoisted dependencies	Dependencies moved to root node_modules lose parent context
Unreferenced dependencies	Dependencies in lockfile but not in package.json aren't tracked
Monorepo edge cases	Complex workspace structures confuse traversal

Issue 3: Missing Reverse Dependency Map

The current implementation relies solely on forward traversal. A reverse dependency map (package@version → Set<parent packages>) would provide a more reliable way to track parent relationships.

[dreyfus92]

cc. @laurathackray21 @43081j

[43081j]

hmm issue 1 doesn't sound like an issue. that code exists specifically to find the parents of duplicate dependencies. so it correctly skips nodes in traversal that have no parent or are not in the duplicates set. i.e. it is traversing to find the duplicates we already know about, to get their parents.

issue 2, lockparse operates solely on the lockfile. it doesn't need to know about hoisting and all that other stuff as long as there's a root lockfile, which there should be.

is the problem here that the monorepo doesn't have a root lockfile?

it is a bug for sure but im not sure the 3 issues here are issues

[abrenneke]

Having the same problem myself. We use pnpm in a monorepo. The root has a lockfile, and that is where I am running pnpm dlx @e18e/cli analyze. Example output:

│    • [duplicate dependency] lru-cache has 4 installed versions:
│      10.4.3 via the following 1 package(s) @asamuzakjp/css-color@2.8.3
│      5.1.1 via the following 1 package(s) @babel/helper-compilation-targets@7.27.2
│      6.0.0 via the following 0 package(s)
│      11.2.4 via the following 0 package(s)
│      💡 Suggestions
│      - Consider upgrading consuming packages as this may resolve this duplicate version.

pnpm why -r --depth 2 lru-cache output:

lru-cache@5.1.1
└── @babel/helper-compilation-targets@7.28.6

lru-cache@6.0.0
├── lru-memoizer@2.3.0
└── openid-client@5.7.1

lru-cache@10.4.3
├── @asamuzakjp/css-color@2.8.3
├── graphql-yoga@5.18.0
└── path-scurry@1.11.1

lru-cache@11.2.4
└── path-scurry@2.0.1

Found 4 versions of lru-cache

[IchordeDionysos]

I've also got an issue:

It throws the following warning:

• [duplicate dependency] @babel/core has 2 installed versions:
│      7.29.0 via the following 5 package(s) jscodeshift@0.16.1, @jest/transform@30.3.0, istanbul-lib-instrument@6.0.3, jest-config@30.3.0, jest-snapshot@30.3.0
│      via the following 0 package(s)
│      💡 Suggestions
│      - Consider standardizing on version 7.29.0 as this version is the most commonly used.                                                                                         
│      - Consider upgrading consuming packages as this may resolve this duplicate version.   

Seems to be a related issue? It only shows me one version of @babel/core, checking the yarn.lock file, it also has only one version of @babel/core but still throws a warning.

[43081j]

that does seem like a bug, we shouldn't be showing a duplicates warning when there are 0 packages 😬

if paul doesn't beat me to it, i can try have a look soon