Polyrepo

A polyrepo setup gives each application or library its own repository, with its own history, pipeline and release cycle.

In a polyrepo, also called multi-repo, every project is isolated at the repository level. A team clones only what it owns. Each repository has its own pipeline, its own dependency versions and its own access rules. Shared code travels as versioned packages through a registry such as npm.

This matches how many organizations are already structured, and it needs no special tooling to start.

Example

A platform has five repositories: shell, orders, invoices, design-system and auth-lib. The design system team publishes a new minor version of @acme/ui to the internal registry. The orders team updates when it is ready by changing the version in its package.json. The invoices team stays on the previous version for another month.

Common misunderstanding

Separate repositories are often equated with independent teams. The coupling still exists. It moves from source code to package versions and runtime contracts. In the example above, production now runs two versions of the design system at once. In a federated setup that can mean two copies of the library in the browser, or a version conflict at runtime.

Cross-cutting changes are also slower. A breaking change in a shared library needs a release and then a pull request in every consumer, and nobody sees the full impact in one place. Teams that choose polyrepo need automation for this: dependency update bots, a shared pipeline template, and a report of which version each application runs.

Neither model is better in general. The choice depends on the number of teams, on how much code is shared and on how much autonomy each team needs. See micro-frontends for how both layouts work in a platform.

Related terms

• Monorepo
• CI/CD pipeline
• Conway's law