Cross-Repo and Cross-Language Dependency Graphs: Tools That Actually Do It

A cross-language dependency graph resolves imports inside each language and stops there, because no import crosses from TypeScript into Go. The links between repos and languages run over HTTP routes, gRPC, queues, shared tables and published packages, so a tool has to match providers to consumers by name. Sourcegraph, GitNexus, Code System Graph and repowise each cover part of that.

The five kinds of cross-language link

The phrase covers five different kinds of link, and they fail in different ways. A tool that says "cross-language" without saying which kind is usually doing the first one.

1. A shared runtime

Java, Kotlin and Scala compile to the same JVM, so a Kotlin file can import a Java class by name. TypeScript and JavaScript share modules the same way, and Vue and Svelte components are TypeScript underneath. Here a real symbol edge across languages is possible. repowise, for example, puts Java, Kotlin and Scala in one shared JVM index, so a Kotlin call can resolve to the Java method it names (Scala's import resolution is partial).

2. Bindings and build steps

Examples are Python calling a C extension and JavaScript calling Rust through WebAssembly or napi (Node-API, Node's interface for native addons). A build step makes the link, so static graphs mostly show two separate islands. On react/react's architecture page, the Rust crates under compiler/crates show up as their own community next to the JavaScript packages. That is the honest picture, because no import statement connects the two.

3. Network contracts

Service A calls POST /v1/orders; service B serves it. Or A publishes to orders.created and B consumes it. Nothing in either file names the other, so the tool has to extract every route and every client call, then match them by path or topic. This is where most of the value is in a microservice system, and where most of the errors are.

4. Shared data

Two services that migrate or query the same table are coupled through the database. Matching an ORM model to a migration is fairly reliable. Matching raw SQL strings in app code is a heuristic.

5. Published packages

Repo B depends on @acme/auth, which repo A publishes. This is the easiest kind to get right, from manifests alone, and the one monorepo build tools already handle once the code is in one place. Migrating 50+ projects into a monorepo covers that case.

Co-change, which is a different signal

Files in different repos that keep changing in the same week give a sixth signal, which is coupling with no dependency behind it. That coupling is real and often the most useful kind, and a graph that mixes it with imports will tell you two files call each other when they don't. Hidden coupling and co-change detection explains how it is computed.

Matching HTTP calls across repos

Extracting a route is the easy half, because @app.get("/users/{id}") is plain text. The hard half is the client side.

• Base URLs hide the service. fetch(`${API_BASE}/users/${id}`) doesn't say which service API_BASE points at, and the value is often in an environment file or a deploy config the code never reads.
• Router prefixes change the path. A handler at /users mounted under app.use('/api', router) in another file is really /api/users, and if the tool misses the prefix, nothing matches.
• Client wrappers hide the call. Most codebases call an apiClient.get() wrapper instead of fetch, so the tool has to follow the wrapper back to its base URL.
• Names built at runtime can't be resolved. Nobody can statically resolve a topic name assembled from a tenant ID.

The right response to each is to label the link: exact when exactly one service provides that path, candidate when several could, and skipped when the name is built at runtime. A tool that draws every plausible edge with the same confidence will look more complete and be wrong more often.

How repowise links repos, and where it stops

I build repowise, so this is the precise version. In a single repo it builds a file and symbol graph from parsed imports and calls, with each edge stamped by how it was resolved, plus co-change from git history. It resolves npm, yarn and pnpm workspaces and tsconfig path aliases in TypeScript, Go multi-module go.mod, Maven and Gradle reactors, Cargo and .csproj projects, so imports across packages inside one repo resolve to files.

Cross-repo linking is a separate layer, called a workspace. Put two or more repos under one folder and run repowise init .. It then extracts:

• HTTP routes and the client calls that hit them, across Express, NestJS, Next.js, FastAPI, Flask, Django, Spring, ASP.NET, Laravel, gin, Axum and more, with router prefixes and axios or ky base URLs stitched in.
• gRPC services from .proto files and client stubs; Kafka, RabbitMQ, NATS, Redis, BullMQ, SQS and SNS topics; socket events; database tables from migrations and ORM models.
• Package dependencies from package.json, composer.json, pyproject.toml, Cargo.toml, go.mod, .csproj and Maven pom.xml.
• Co-change pairs across repos, kept as a separate edge kind.

Everything lands in one system graph where nodes are services and every edge carries a kind, a match type (exact, candidate, manual or inferred), and pointers back to the evidence. repowise workspace diagnostics lists each unmatched call with a reason: no provider, internal only, unlinked, or an external host like Stripe.

These are the limits:

• The cross-repo layer needs at least two repos in a workspace. A single monorepo indexed alone gets the import graph but no HTTP contract layer.
• repowise skips names built at runtime and does not guess them. If API_BASE is unresolved and several services serve that path, you get a candidate, or you map it yourself under service_bases in the workspace config.
• SQL strings in app code are matched heuristically, and data contracts get no field-level breaking-change check.
• Calls through bindings or WebAssembly aren't linked.
• Inside one repo, roughly fifteen percent of call edges are wrong in our own hand-graded sample, concentrated in Java, Rust and C++. That figure is from the graph layer docs, with the method.

The cross-repo docs list every framework and client the extractors read. For how the single-repo graph is built, see building a dependency graph for any codebase.

How to test any tool's cross-repo claim

These checks work on every tool in the table, including ours.

1. Pick a call you know, such as one frontend request and the backend route it hits, and see whether the tool links them and points at the right handler.
2. Ask for the misses. A tool that can list the calls it located but couldn't match is telling you its recall (how many of the real links it finds), and one that can't is asking you to trust it.
3. Look for confidence labels, because exact and guessed links should look different.
4. Try a dynamic name, such as a URL from an environment variable or a topic built from a string. The right answer is "unresolved", and a confident edge is a wrong answer.
5. Check co-change separately. If a tool says two files depend on each other, ask whether that came from code or from history.

For JavaScript and TypeScript inside one repo, 5 ways to generate a JS/TS dependency graph has runnable commands for madge, dependency-cruiser, Nx, esbuild and repowise.

How we measured

On 2026-10-06 we read each tool's own docs or README for the claims in the table: Sourcegraph's code navigation docs, the GitNexus and Code System Graph READMEs, MindGraph's listing, Backstage's descriptor format and Grafana Tempo's service graph docs. We did not run the other tools on a shared set of repos, so the table says what each one documents and cannot say how well it does it. repowise claims come from the OSS docs and source at commit e83befa, and the react/react observation from its live architecture page the same day.