missingNodeModulesDetection false positives in pnpm strict node_modules layout

[drPytho]

[Disclaimer] This issue was partially created by AI, and audited and verified by me (If this is not appreciated I am happy to remove the issue)
I am also working on a fix for the issue, just want to make sure this is not something out of scope for the project.

missingNodeModulesDetection doesn't work with pnpm strict node_modules

Problem

missingNodeModulesDetection flags every workspace-specific dependency as "missing" in a pnpm monorepo.

pnpm uses a strict node_modules layout by default: workspace dependencies are only symlinked into each workspace's own node_modules/, not the root. rev-dep's missingNodeModulesDetection only checks the CWD resolver's nodeModules map, so any dependency declared in a workspace package.json (but absent from the root node_modules/) gets flagged as missing.

In a monorepo with 100+ workspaces this produces hundreds of false positives, making the check unusable.

orphanFilesDetection has a related issue: workspace src/index.ts files appear orphaned because they're only reachable via cross-package imports that the orphan analysis doesn't trace through.

Reproduction

pnpm monorepo, strict node_modules (default pnpm behavior):

my-monorepo/
  package.json              # root — no @ai-sdk/cerebras here
  node_modules/             # only root-level deps hoisted here
  packages/
    llm-clients/
      package.json          # "@ai-sdk/cerebras": "^4.0.0"
      node_modules/
        @ai-sdk/cerebras/   # symlinked by pnpm ✓
      src/
        index.ts            # import { ... } from '@ai-sdk/cerebras'

Config (single rule or per-workspace — same result):

{
  "configVersion": "1.5",
  "rules": [
    {
      "path": "packages/llm-clients",
      "followMonorepoPackages": true,
      "missingNodeModulesDetection": { "enabled": true }
    }
  ]
}

Result:

❌ Missing Node Modules Issues (1):
  - @ai-sdk/cerebras (imported from: packages/llm-clients/src/index.ts)

Expected: no issues — the package is declared and installed in the workspace.

Workarounds tested (none worked)

• Per-workspace rule with path: "packages/llm-clients" — same false positive
• --package-json packages/llm-clients/package.json CLI flag — same
• Direct version "^4.0.0" instead of pnpm "catalog:" — same

Root cause

In nodeModules.go (~lines 168-174), GetMissingNodeModulesFromTree receives only the CWD resolver's node modules:

resolverForCwd := resolverManager.GetResolverForFile(cwd)
cwdNodeModules := resolverForCwd.nodeModules
// ...
GetMissingNodeModulesFromTree(tree, cwdNodeModules, ...)

The CWD resolver points at the root package.json, so only root-level dependencies are in cwdNodeModules. Workspace dependencies are held by their own resolvers but never consulted.

The monorepo infrastructure already handles this — ResolverManager creates a resolver per workspace and CollectAllNodeModules() (lines 288-306) aggregates them. It's just not called here.

Proposed fix

missingNodeModulesDetection (small change)

Replace the CWD-only lookup with the existing aggregation method:

// Before:
resolverForCwd := resolverManager.GetResolverForFile(cwd)
cwdNodeModules = resolverForCwd.nodeModules

// After:
cwdNodeModules := resolverManager.CollectAllNodeModules()

CollectAllNodeModules() already iterates all resolvers (root + workspace packages) and merges their nodeModules maps. This single change should fix the false positives.

A more precise alternative: for each flagged import, look up the resolver for the importing file (GetResolverForFile(importingFile)) and check that resolver's nodeModules. This would be per-file accurate rather than a global merge, but the global merge is simpler and sufficient since a "missing" module that exists in any workspace resolver is clearly installed.

orphanFilesDetection (medium change)

When followMonorepoPackages is enabled, automatically treat each workspace's entry points (derived from package.json exports/main fields) as valid entry points for the orphan analysis. This would require:

1. In MonorepoContext.FindWorkspacePackages() — extract entry points from each workspace's package.json
2. Pass these as additional validEntryPoints to FindOrphanFiles()
3. Estimated 2-3 functions to modify

Environment

• rev-dep: 2.9.1
• pnpm: 10.x (strict node_modules layout)
• Config version: 1.5

[jayu]

Hi, I cannot reproduce that, check this repo https://github.com/jayu/rev-dep-demo/tree/missing-packages

rev-dep resolves node-modules only based the closed package.json dependencies/devDependencies definition

So in your case it should not detect missing dependencies.
If you define "@ai-sdk/cerebras": "^4.0.0" in root package.json - then it would report missing dependency.

So I think there might be an issue with workspaces detection - how do you define pnpm workspaces in you project.

You can adjust the repro from linked repository to match your exact setup, you can fork it and modify, so I can debug.

To check if workspaces detection works in your project, run rev-dep config init in repo root. If workspaces are detected correctly, then you should have rules created for each workspace. If you have 100+ workspaces then there should be 100+ rules generated

[jayu]

Hi @drPytho did you had a chance to check my repro? I would like to make sure it works for different pnpm setups. A way of defining the actual workspaces might be crucial, maybe your project defines them in a way that rev-dep does not cover

[drPytho]

#23 i tried to re-create the setup in a test in this PR

[drPytho]

This patch solved some of the issues I had, did not start the PR yet since I was still working though the last issues (trying to figure out if they were with my setup or with rev-dep). Trying to migrate a large monorepo over to rev-dep.

[jayu]

I've checked your PR and here are my conclusions

Monorepo packages resolution issues

There has been a bug in how rev-dep process glob patterns when detecting monorepo packages.

Issue 1: Non-trailing glob patterns like path/**/path/* or path/**/* have been incorrectly interpreted as <prefix> + *
Issue 2: Nested workspaces have not been discovered for pattern with trailing /** eg packages/**

• Correctly discovered package/pkg1, package/deep/pkg2, package/deep/pkg3, package/deep/deep/deep/pkg4 etc.
• Not correctly discovered package/deep/pkg2/packages/pkg2-1 package/deep/pkg2/packages/pkg2-2
  • essentially when package was nested in directory which contains other package, it was not discovered

These has been fixed in 2.11.0

Orphan files detection for shared packages without entry points

I understand your concern about reported orphan files in shared packages that are only imported by other packages in the workspace.

The test you've created are using rev-dep internals, so I'm not sure how you actually try to make it work in rev-dep.

Here is how I solved that in my project (simplified).

We have packages

packages/web
packages/mobile
packages/shared

and entry points

packages/web/index.ts
packages/mobile/index.ts

packages/shared is simply just in time package, both web and mobile imports from it directly (in my case via ts aliases, but it might be also package.json exports map)

In rev-dep config we do have

For packages/web

• orphan files detection, validEntryPoints : ['index.ts']

For packages/mobile

• orphan files detection, validEntryPoints : ['index.ts']

For packages/shared

• orphan files detection is disabled

We have additional monorepo root level setting with "path": "." . We use it to detect files that are not imported by any other file in the whole monorepo

• orphan files detection, validEntryPoints : ['packages/web/index.ts','packages/mobile/index.ts']

So that if there is a file in packages/shared that is not used anywhere, it will be reported.

I'm not sure if that covers your use case.
If it does not, think of validEntryPoints as a list of files that is expected to not be imported by any other file, you can add whatever you want there, seems like additionalEntryPointFiles is not needed.
In rev-dep config file you can add comment to split list of actual entry points, from some false positives, if that helps.

missingNodeModulesDetection false positives

Based on the example in test my understanding is that you try to achieve exactly what rev-dep supports, which is strict definition of packages for each workspace.
If file in workspace imports some 3rd party package, is has to be defined in this workspace package.json as dependency or dev dependency, otherwise will be reported as missing.

Rev dep does not check what's inside your node_modules directories, it only checks if packages are defined in correct package.json

How packages are distributed across node_modules directories is package manager and bundler / runtime concern. Rev-dep only checks declaration correctness.

So it should work for you as long as workspaces are correctly discovered - now it should be after the fix.

I hope that helps. If you still have some issues, small repository with reproduction would be the best way to move forward.