Monorepo

Adopting a monorepo approach for our React and Next.js-based projects offers several benefits, although it may not be the best fit for every project.

1. More efficient code sharing and reusability.
2. Consistent development environment.
3. Easier cross-project refactoring.
4. Improved collaboration.
5. Simplified Dependency Management: In our monorepo, we can manage dependencies at the repository level, simplifying the process of keeping everything up to date and avoiding version conflicts.
6. Streamlined CI/CD Pipeline: A single CI/CD pipeline that can build and test all our projects simultaneously. This, of course, comes with the drawback of a more complicated CI/CD setup and potentially longer running pipelines.
7. Better Code Ownership: It's easier to determine who is responsible for each part of the codebase, which can improve code ownership and accountability.
8. Simplified Testing: We can set up end-to-end tests and integration tests that cover the entire application more easily in a monorepo, ensuring that changes in one part of the codebase don't break other parts.
9. Codebase Navigation: Developers can easily navigate through different parts of the codebase without having to switch between multiple repositories or projects.

However, it is important to note that monorepos are not a one-size-fits-all solution. They can introduce complexity, especially in very large projects, and may not be suitable for all team sizes or development workflows. The decision to adopt a monorepo should be based on a careful consideration of your project's specific requirements, team size, and development practices.

A monorepo is a single repository containing multiple projects and shared libraries with their relationships.

At AOE, we are using a monorepo that is home to both our React and Next.js based frontends and Go / Flamingo based backends, as well as shared libraries we use in all of our projects.

The main benefits in that approach are:

• Breaking changes are directly detected and must be fixed within the same pull request on all projects
• No conflicting versions of dependencies
• Same CI Setup for everything and no overhead on new projects
• Tool consistency over all projects

If you take the monorepo approach, of course you want to have a tool to manage it. There are a lot of them on the market and at AOE we have decided to go with Nx.