Multi-Project Monorepo Contract Build Coordinator

WHAT IT DOES

Multi-Project Monorepo Contract Build Coordinator analyzes your monorepo structure to determine the correct build order for multiple smart contract projects that depend on each other. It reads project configuration files (foundry.toml, hardhat.config.js, truffle-config.js) to identify each subproject's type and location, then builds a dependency graph from user-provided relationships between projects. The tool performs a topological sort to produce a build sequence that respects all dependencies—ensuring that a project is built before any project that depends on it. The output includes a visual dependency graph, build order list with step numbers, and summary statistics including configuration types, total projects, and circular dependency detection. This helps monorepo maintainers avoid build errors caused by incorrect build ordering, especially when projects share compiled artifacts or import from each other.

HOW TO USE

Paste a list of projects into the first text area, one per line with the format "path,config-type" (e.g., "packages/core,foundry" or "contracts/main,hardhat"). The config type helps identify which build tool each project uses. In the second text area, define the dependency graph with lines like "project: dependency1, dependency2". For projects with no dependencies, leave the right side empty (e.g., "utils:"). Click "Coordinate build order" to perform the topological sort. Results display each project in build order with its dependencies, configuration type, and a visual dependency chain. The summary shows total projects, the full build order sequence, configuration distribution, and whether any circular dependencies were detected.

TECHNICAL MECHANISM: DEPENDENCY GRAPH TOPOLOGICAL SORT WITH CYCLE DETECTION

The coordinator uses Kahn's algorithm for topological sorting, adapted to detect cycles in the dependency graph. It first builds an adjacency list from the user-provided dependency definitions, then computes in-degree for each project. Projects with zero dependencies are queued first, and as each project is processed, its outgoing edges are removed, reducing the in-degree of dependents. The algorithm iterates until all projects are either placed in the build order or a cycle is detected. If a cycle is found, the tool reports the exact circular dependency, preventing an invalid build sequence from being generated. The graph is also rendered visually with nodes representing projects and arrows showing dependency direction. This same algorithm underpins build systems like Make, Bazel, and Foundry's own build coordination, but this tool provides a lightweight, language-agnostic view that works across different build tool configurations without executing any compilations.

WHAT IT CANNOT SEE

Cannot execute builds or compile contracts itself—it only analyzes structure, not actual code. Cannot resolve cross-project dependency conflicts automatically, such as different versions of the same library imported by different subprojects. Cannot detect mismatched compiler versions across subprojects—each project's config is read but not validated against others. Cannot verify that artifacts from different projects are compatible at the bytecode level. Cannot identify circular dependencies between projects beyond what the user provides; it relies on explicit input. Cannot ensure that all subprojects use the same Solidity version or optimizer settings; these are read but not cross-checked. Cannot detect that a subproject's build is stale without checking timestamps. Cannot validate that the coordinated build order actually produces working deployments—it cannot test the resulting artifacts. Cannot account for external dependencies that are not mirrored in the monorepo, such as packages installed via npm or foundry's git submodules. Cannot determine if a project's build configuration is correct or will succeed; it trusts that the user's configs are valid.

PLEASE NOTE

EVM chains only. This tool reads local configuration and does not interact with any blockchain. It is read-only and does not modify your monorepo.