Best Dependency Graph Tools for Monorepos

best dependency graph tools for monorepos is a narrower question than it looks. Most teams start with a graph that answers build order, then discover they need package boundaries, symbol-level edges, circular dependency detection, and change impact. A monorepo dependency graph that only shows package-to-package links is useful. A graph that also knows ownership, churn, dead code, and why a file exists is better. This post compares the tools I reach for, where each one fits, and where each one stops. For repowise, the dependency graph is one layer in a larger codebase intelligence stack: docs, git history, hotspots, and MCP access for AI agents. (repowise.dev)

Why monorepo dependency graphs blow up

A small repo can survive on mental models. A monorepo cannot. Once you have 50, 200, or 2,000 packages, the old tricks stop working:

1. You cannot tell which package change will break downstream code.
2. You cannot see hidden cycles until they slow refactors.
3. You cannot separate build dependencies from source dependencies.
4. You cannot tell whether a file is central, noisy, or just old.
5. You cannot answer “what changes if I touch this?” without running half the repo.

That is why dependency analysis tool choices matter. The graph is not just a picture. It is the data structure behind affected builds, architecture checks, ownership review, and agent context. Nx treats the project graph as a workspace-wide model used for affected commands, caching, and task execution. Turborepo models the repo as package and task graphs. Both are built for monorepos, but they optimize for build orchestration first. (nx.dev)

Monorepos also create a second problem: the graph can lie if it is too coarse. A package graph can say “A depends on B” while the real risk sits in one symbol, one import, or one internal utility file. That is where code dependency visualization needs a second layer. Repowise builds a directed graph from Tree-sitter ASTs across 10+ languages and then adds PageRank, betweenness centrality, edge types, and git-based signals on top. That lets it answer “what is important?” instead of only “what imports what?” (repowise.dev)

Monorepo Graph Layers

The two layers: package and symbol

The fastest way to pick the right tool is to ask which layer you need.

Package dependency monorepo view

This is the workspace-level view. It answers:

• Which packages depend on this package?
• What breaks if I rename a workspace package?
• What is the build or release order?
• Where are the cycles between packages?

Nx Graph and Turborepo both live here. Madge can help too, but it is usually more file-oriented than workspace-oriented. Dependency-Cruiser can work at this level if you configure it that way. (nx.dev)

Symbol-level code dependency visualization

This is the file, module, class, or function view. It answers:

• Which function actually owns the risk?
• Which internal API is the shared choke point?
• Which file creates the cycle?
• What is a safe refactor boundary?

This is where package graphs run out of detail. Repowise is the strongest option in this list because it does not stop at packages. It generates docs for files, modules, and symbols, then overlays graph intelligence and git history. That makes it useful for large TypeScript, Python, Go, Java, Rust, and C-family codebases where a package boundary hides too much. (repowise.dev)

1. repowise: cross-package plus symbol level

Repowise is the best choice when you want the graph to explain the repository instead of merely draw it. The core pitch is simple: index the repo, build a dependency graph, then add docs, ownership, hotspots, dead code, and decision records around it. The docs describe a queryable knowledge graph exposed through MCP tools, and the public site shows dependency graphs, hotspots, and generated documentation over real repos such as FastAPI. (docs.repowise.dev)

Where repowise stands out

• Cross-package plus symbol intelligence. It parses ASTs, not just package manifests. That matters in a monorepo where most architectural pain sits below the package level. (repowise.dev)
• Git intelligence attached to the graph. Hotspots, ownership, co-change pairs, and bus factor tell you where the graph is fragile. (repowise.dev)
• Dead code detection. A dependency graph is far more useful when it also shows what is unreachable. (github.com)
• MCP access for agents. The Model Context Protocol is an open standard for connecting AI apps to external systems, and its current spec defines a client-host-server architecture with structured tools and lifecycle management. Repowise exposes seven MCP tools in its docs and GitHub repo, so AI editors can ask for graph context instead of guessing from raw files. (modelcontextprotocol.io)

Where repowise is not the default

If your only need is task orchestration, it is more tool than you need. If you want a narrow CLI just to spot circles in a JavaScript tree, Madge is simpler. If you want strict rule-based dependency enforcement in a workspace, Dependency-Cruiser is more direct.

Repowise earns its keep when the question is not “what depends on what?” but “what is this repo actually doing, who owns it, and what will break if I change it?” See the architecture page to understand how repowise works, or browse the live examples to inspect a real index. (repowise.dev)

2. Nx Graph

Nx is the strongest all-around monorepo platform in this list if your main job is coordination. Its project graph tracks projects and dependencies inside the workspace, and its task graph uses that structure to decide build order, caching, and affected tasks. Nx also exposes graph exploration in the UI and CLI. (nx.dev)

Best for

• Teams already using Nx for task running and affected builds.
• TypeScript-heavy workspaces.
• Boundaries enforced by config and tags.
• A graph tied directly to CI behavior. (nx.dev)

Limits

Nx is a workspace graph first. It tells you how projects relate, but it does not try to become a full code intelligence layer. If you need ownership maps, code health, or symbol-level explanation, you will still need another dependency analysis tool beside it. Nx itself acknowledges that the project graph is used for affected commands and caching; that is the value. The rest is on you. (nx.dev)

3. Turborepo task graph

Turborepo is the cleanest answer if you care about package dependencies and task execution more than static analysis. Its docs describe a package graph generated from your package manager and a task graph represented as a DAG. That is ideal for orchestrating build, lint, and test pipelines in a package dependency monorepo. (turborepo.com)

Best for

• JavaScript and TypeScript monorepos.
• Build caching and task pipelining.
• Teams that want low ceremony.
• Simple workspace graphs that map closely to npm, pnpm, or yarn packages. (turborepo.com)

Limits

Turborepo is not a graph exploration product. It is a task runner with graph awareness. That makes it excellent for execution and less strong for architecture review. If you need circular dependency reports, dead code detection, or a deep code dependency visualization, it is not enough on its own. (turborepo.com)

4. Madge

Madge is the quickest tool to reach for when you want a fast graph and a circular dependency report, especially in JavaScript. Its npm page says it generates a visual graph of module dependencies, finds circular dependencies, and works with AMD, CommonJS, ES modules, and CSS preprocessors. It also supports CLI flags for --circular, --orphans, --leaves, and SVG or DOT output. (npmjs.com)

Best for

• Spotting circular dependencies quickly.
• Small-to-medium JS and TS codebases.
• One-off audits.
• Exporting graphs to Graphviz for review. (npmjs.com)

Limits

Madge is file/module oriented. It is handy, but it does not model the rest of monorepo life: ownership, history, change risk, or multi-language repos. It is a graph utility, not a code intelligence platform. (npmjs.com)

Where Madge shines in practice

If I am debugging a nasty import loop in a JavaScript package, Madge is often the fastest first pass. If I need to understand the repo as a system, I move to a broader tool.

5. Dependency-Cruiser

Dependency-Cruiser sits between a graph viewer and a policy engine. It is built around dependency rules and circular dependency checks for JavaScript and TypeScript projects. That makes it a good fit for teams that want to encode architectural constraints in config and fail CI when code crosses a boundary.

I could not verify a current primary docs page from the search results above, so I am not going to overstate the product details. In practice, it belongs in the same bucket as Madge, but with a stronger bias toward rule enforcement than quick visualization.

Best for

• Rule-based boundary checks.
• CI enforcement of allowed imports.
• Teams that want dependency constraints, not just a picture.

Limits

It is less about whole-repo understanding and more about policy. If you want a richer monorepo dependency graph that includes history and risk, it will not replace a broader intelligence layer.

Comparison matrix

How to choose

1. Pick Nx if your first problem is build and CI flow.
2. Pick Turborepo if your first problem is task execution in JS/TS.
3. Pick Madge if your first problem is a cycle in module imports.
4. Pick Dependency-Cruiser if your first problem is policy enforcement.
5. Pick repowise if your first problem is understanding the repo itself. (nx.dev)

Spotting circular dependencies

Cycles are the same bug in different clothes. A cycle in a monorepo dependency graph usually means one of four things:

• a shared utility became a dumping ground,
• a package boundary is wrong,
• two modules own the same concept,
• or an import shortcut masked a design problem.

Madge is good at showing the cycle. Nx helps you avoid them by shaping project boundaries. Dependency-Cruiser helps you ban them. Repowise helps you see why the cycle exists by pairing the graph with ownership, change history, and file health. That is the difference between “here is the loop” and “here is the refactor target.” (npmjs.com)

A practical cycle-finding workflow

1. Run the workspace graph first.
2. Check the affected path.
3. Inspect the smallest loop.
4. Ask who owns the files.
5. Check whether the files are hotspots.
6. Break the cycle at the lowest-risk boundary.

If you use repowise, the get_dependency_path() and get_risk() MCP tools are built for this exact flow. The docs also expose get_overview(), get_context(), get_why(), search_codebase(), get_dead_code(), and get_architecture_diagram() for agents that need a fuller picture. (docs.repowise.dev)

Dependency Cycle Debugging

Best dependency graph tools by use case

Choose repowise if you need:

• monorepo dependency graph plus symbol-level context,
• ownership and hotspot analysis,
• dead code detection,
• AI agent access through MCP,
• self-hosted open source with AGPL-3.0 licensing. The AGPL is designed for network server software, which is relevant when a tool is served to users over a network. (gnu.org)

Choose Nx if you need:

• project graphs tied to affected commands,
• task graphs and caching,
• workspace enforcement,
• strong monorepo workflow support. (nx.dev)

Choose Turborepo if you need:

• a package graph and task pipeline,
• quick setup,
• a clean build-oriented monorepo model. (turborepo.com)

Choose Madge if you need:

• circular dependency checks,
• a simple module graph,
• SVG or DOT output fast. (npmjs.com)

Choose Dependency-Cruiser if you need:

• import rules,
• policy enforcement,
• CI checks for architecture drift.

How repowise fits alongside these tools

A good monorepo stack usually has more than one graph.

• Nx or Turborepo runs the work.
• Madge or Dependency-Cruiser guards module boundaries.
• Repowise explains the repo and shows where the risk lives.

That combination is hard to beat because each tool solves a different layer. The mistake is asking one tool to do all three jobs: build orchestration, boundary enforcement, and code understanding. The graph gets blurry fast. Repowise’s public examples are a useful way to sanity-check this. Open the FastAPI dependency graph demo and compare it with the auto-generated docs for FastAPI; the graph and the documentation are built from the same index, so the context stays aligned. (repowise.dev)

FAQ

What is the best dependency graph tool for monorepos?

If you want one tool for deep understanding, I would pick repowise. If you want one tool for build coordination, pick Nx. If you want quick cycle detection in JavaScript, pick Madge. The right answer depends on whether your main problem is architecture, execution, or import hygiene. (docs.repowise.dev)

Which tool is best for package dependency monorepos?

Turborepo and Nx are the best fits if the repo graph mainly exists to drive tasks, caching, and affected builds. Nx gives you more workspace intelligence. Turborepo gives you a lighter task-centric model. (nx.dev)

Which dependency analysis tool finds circular dependencies fastest?

Madge is usually the fastest first pass. It has an explicit --circular mode and a simple CLI. Dependency-Cruiser is stronger if you want to enforce rules after you find the cycle. (npmjs.com)

What is the difference between package graph and symbol graph?

A package graph shows relationships between packages or projects. A symbol graph goes deeper and tracks files, modules, classes, functions, or other named units. Package graphs help with build order and release flow. Symbol graphs help with refactors, ownership, and bug isolation. (nx.dev)

Does MCP matter for dependency graph tools?

Yes, if you want AI agents to work from structured repo context instead of raw file text. MCP is an open standard for connecting AI applications to tools and data sources, and its spec defines a client-host-server model. Repowise uses that model to expose repo knowledge through tools that editors and agents can call. (modelcontextprotocol.io)

Is AGPL a bad fit for internal monorepo tools?

Not automatically. AGPL-3.0 is designed for network server software, so it is often chosen for self-hosted systems that are exposed over a network. Whether it fits your company policy is a legal question, not a technical one. (gnu.org)

Can I use repowise on a private monorepo?

Yes. The public product and docs describe self-hosted and hosted use, and the GitHub repo says it indexes code into dependency graphs, docs, and git analytics for AI-assisted engineering teams. (repowise.dev)

If you want to try it on a real workspace, start with repowise on your own repo or install it directly with pip install repowise && repowise init.