TikTok's 200K-File Frontend Monorepo
Large frontend monorepos through dependency graphs, selective builds, and tooling.
A frontend monorepo with hundreds of thousands of files is not impressive by file count alone. It is only useful if engineers can still build, test, search, refactor, and release changes without drowning in dependency noise. TikTok's public engineering story around a very large frontend monorepo points to a familiar problem at unusual scale: the repository becomes a coordination system as much as a code container.
Why teams choose a monorepo
A monorepo makes shared components, design tokens, build configuration, and internal libraries easier to discover and reuse. Cross package refactors can happen atomically, and dependency versions stay aligned. For a large product organisation with many surfaces, this can be far cheaper than maintaining dozens of loosely coordinated repositories.
The downside appears once the repo grows. Fresh clones get slower, package graphs become dense, and a small change can trigger far too much work in CI if the tooling does not understand project boundaries.
What large scale repo tooling must do
The first requirement is dependency graph awareness. Build and test systems need to know which packages truly depend on which others so they can run affected work only. Without that, every pull request behaves like a repo wide event and developer feedback loops collapse.
The second requirement is caching. Frontend build steps are expensive, especially with TypeScript, bundling, linting, and asset pipelines. Remote caches and deterministic task outputs let many developers reuse the same work instead of recompiling identical artefacts repeatedly.
The third requirement is ownership. A giant repo without clear code ownership quickly becomes socially unscalable. Teams need directory conventions, review routing, and boundaries for what can be imported from where.
Why file count is not the real bottleneck
Large monorepos usually fail because of graph shape, not storage size. If foundational packages change too often or if everybody depends on everybody else, incremental tooling loses its power. The best monorepo systems therefore constrain architecture. They make some dependencies easy, some expensive, and some impossible.
For frontend codebases, local development also matters. Editors need fast indexing. Type checking must be partitioned. Generated code must not flood watch mode. A system that performs well in CI but feels sluggish on a laptop is still a poor developer platform.
Tradeoffs and limits
Monorepos centralise reuse and governance, but they also centralise failure. A broken root configuration can block many teams. Migration work becomes easier to coordinate but harder to avoid. Access control can also become tricky if not all code should be equally visible.
A 200k file frontend repo is manageable when the platform team invests in graph aware task execution, caching, code ownership, and conventions that stop the dependency structure from collapsing into a knot. The lesson is not that huge repos are inherently good. It is that they demand platform engineering discipline equal to the product complexity they contain.