Monorepo Support

ghostdep automatically detects monorepos and handles cross-project imports correctly.

How it works

When ghostdep finds multiple manifest files in nested directories, it treats each one as a separate project scope. It builds an internal package index from the directory names and excludes cross-project imports from phantom findings.

my-monorepo/
├── packages/
│   ├── api/
│   │   ├── package.json    ← scope 1
│   │   └── src/index.js
│   ├── web/
│   │   ├── package.json    ← scope 2
│   │   └── src/app.js
│   └── shared/
│       ├── package.json    ← scope 3
│       └── src/utils.js

If api/src/index.js imports @myorg/shared, ghostdep recognizes shared as an internal package and won’t flag it as phantom.

Scoping

Each project scope is analyzed independently:

• Imports in api/ are matched against api/package.json
• Imports in web/ are matched against web/package.json
• Cross-project imports are excluded from phantom results

Mixed languages

Monorepos with different languages work fine:

my-monorepo/
├── services/
│   └── api/
│       ├── go.mod
│       └── main.go
├── frontend/
│   ├── package.json
│   └── src/app.tsx

Each sub-project uses its own language plugin.

Limitations

• Internal package detection uses directory names, not the name field from manifests (planned improvement)
• Deeply nested workspaces (workspace-of-workspaces) aren’t specially handled — each manifest is a flat scope