The Hope of Monorepos: How a Repository of Despair Became Hope Again in One Year

Toss has over 100 frontend engineers developing mobile products in a single monorepo, maintaining the same development environment with tools like React 19 and Next.js 15. This allows them to share the latest features such as React Concurrent Mode and React Server Components, making code sharing and propagating platform changes easier.

However, as services increased, dependency versions within the monorepo diverged. Some services used the latest React, while older services had to maintain outdated libraries and slow development environments, with dependency installation taking over a minute even with caching.

The platform team also considered splitting the monorepo into multiple repositories, known as Polyrepo. However, they determined that while Polyrepo could improve installation speed, it would not solve issues related to development environment fragmentation, the cost of updating common code, and the difficulty of testing platform libraries, and could actually exacerbate fragmentation.

The core cause was that each service had different versions of 10 to 20 core libraries, including React, component libraries, state management tools, TypeScript, and ESLint. Noting that most developers decide whether they need a specific library but do not manually select the detailed version, the platform team decided to provide standard library versions.

To achieve this, they defined a bundle of recommended standard versions for all services as a Catalog. This strategy leverages the catalog feature provided by pnpm and Yarn to manage common dependency versions in monorepos, simplifying the dependency tree and improving consistency in development environments and platform updates across services.