Why a frontend monorepo
When you have multiple frontend apps and packages, a monorepo can streamline and accelerate your development and release cycles.
Why a frontend monorepo?
A frontend monorepo brings developer experience, productivity as well as cross-team collaboration benefits:
-
Consistent and shared configurations: Your build configuration (webpack, vite, etc.) is in one place, and as you evolve it, all your apps benefit. The same goes for your typescript, formatting, and linting configurations. This means a unified and consistent development environment that is easy to follow.
-
Simplified dependency management: No more cloning and pull requests to dozens of repositories to publish and update dependencies.. Everything is done in one step with simplified release cycles.
-
Easier cross-team contributions: Say you are rolling out a new loyalty program that touches multiple apps and frontend products. With a monorepo, it’s easy for the project team to find and update all the related code without having to adapt to different codebases.
The larger the team, the greater the productivity gains due to the centralized and opinionated setup that a frontend monorepo provides.
Tools to set up your frontend monorepo for success
I will cover the basics with an easy to evolve setup.
-
Start with workspaces: npm, yarn and pnpm all support workspaces natively. Workspaces help you organize your monorepo into different projects or packages, while allowing you to install and manage them centrally. Package managers will optimize and dedupe your dependencies and allow you to seamlessly symlink dependent local packages. I have a sweet spot for pnpm which further optimizes to your dependencies installation.
-
Once you are up and running and want further optimizations such as faster builds by optimizing tasks and using local and remote caching capabilities, you will want to integrate with a build system. Nx and Turborepo stand out: both are easy to adopt incrementally on top of workspaces and are well integrated into the JavaScript ecosystem.
-
Enforce formatting styles with Prettier and coding guidelines with ESLint. Opinions are good, but you don’t want your code reviews to be about tabs vs spaces and you want to statically catch early as many pitfalls as possible. It’s cheaper to fix potential bugs in developer editors than in production.
-
Introduce code owners: Supported by both GitHub and GitLab, a CODEOWNERS file allows you to define individuals or teams responsible for code (folders or files) in a repository. This helps streamline the review process by ensuring that relevant people are tagged and approve code changes for which they are responsible.
There are of course many other great tools out there to manage your frontend monorepo but these will get you very far without adding too much complexity to your frontend stack.
At Zalando, even without a build system, we safely merged and deployed over 400+ change requests per month, submitted by over 100 individual contributors.
