Monorepo
Fleeting- External reference: https://trunkbaseddevelopment.com/monorepos/
- External reference: https://systemseed.com/articles/automated-releases-in-a-cross-language-monorepo
- External reference: https://www.rocketpoweredjetpants.com/2017/11/organising-a-monorepo/
- External reference: https://monorepo.tools/
- External reference: https://blog.nrwl.io/misconceptions-about-monorepos-monorepo-monolith-df1250d4b03c
I have the feeling that arguments in favor of monorepos that don’t take into account the social structure of the developper is missing the point. To me monorepos is not about better structure of the code, but about structure of the code that better fits the structure of the people when it makes sense. (Conway’s law).
Monorepo-style development is a software development approach where:You develop multiple projects in the same repository.The projects can depend on each other, so they can share code.When you make a change, you do not rebuild or retest every project in the monorepo. Instead, you only rebuild and retest the projects that can be affected by your change.
— https://blog.nrwl.io/misconceptions-about-monorepos-monorepo-monolith-df1250d4b03c
Monorepos and long-lived feature branches do not play together nicely. Chances are you will have to adopt some form of trunk-based development
— https://blog.nrwl.io/misconceptions-about-monorepos-monorepo-monolith-df1250d4b03c
Moving to a monorepo requires you to rethink how you do continuous integration. After all, you are no longer building a single app. You are only building the things that are affected by your change.
— https://blog.nrwl.io/misconceptions-about-monorepos-monorepo-monolith-df1250d4b03c
Monorepos are known for the following benefits:Everything at that current commit works together. Changes can be verified across all affected parts of the organization.Easy to split code into composable modulesEasier dependency managementOne toolchain setupCode editors and IDEs are “workspace” awareConsistent developer experience
— https://blog.nrwl.io/misconceptions-about-monorepos-monorepo-monolith-df1250d4b03c
monorepo is a single repository containing multiple distinct projects, with well-defined relationships.
repository with several projects in it. We definitely have “code colocation”, but if there are no well defined relationships among them, we would not call it a monorepo.
repository contains a massive application without division and encapsulation of discrete parts, it’s just a big repo. You can give it a fancy name like “garganturepo,” but we’re sorry to say, it’s not a monorepo.
good monorepo is the opposite of monolithic
opposite of monorepo is a “polyrepo”. A polyrepo is the current standard way of developing applications: a repo for each team, application, or project. And it’s common that each repo has a single build artifact, and simple build pipeline.
why should teams do anything differently? Because this autonomy is provided by isolation, and isolation harms collaboration.
No overhead to create new projectsUse the existing CI setup, and no need to publish versioned packages if all consumers are in the same repo
Atomic commits across projectsEverything works together at every commit. There’s no such thing as a breaking change when you fix everything in the same commit
Language-based monorepos These repos contain a top-level directory per language
— https://www.rocketpoweredjetpants.com/2017/11/organising-a-monorepo/
Project-based monorepos
— https://www.rocketpoweredjetpants.com/2017/11/organising-a-monorepo/
co-locate everything needed for a particular project in the same directory, with common code being stored “elsewhere”
— https://www.rocketpoweredjetpants.com/2017/11/organising-a-monorepo/
Functional area-based monorepos
— https://www.rocketpoweredjetpants.com/2017/11/organising-a-monorepo/
For example, there might be a directory for “crypto” related code, another for “testing”, another for “networking” and so on
— https://www.rocketpoweredjetpants.com/2017/11/organising-a-monorepo/
Blended monorepos
— https://www.rocketpoweredjetpants.com/2017/11/organising-a-monorepo/
hybrid approach is typically simpler to work with.
— https://www.rocketpoweredjetpants.com/2017/11/organising-a-monorepo/
example, project-based monorepos rapidly have a cluttered top-level directory. However, by splitting by functional area, or language and then functional area, the top-level becomes less cluttered and simultaneously easier to navigate.
— https://www.rocketpoweredjetpants.com/2017/11/organising-a-monorepo/
Third party dependencies
— https://www.rocketpoweredjetpants.com/2017/11/organising-a-monorepo/
. Do you take binary dependencies, or pull in the source? Do you store the third party code in a separate third party directory, or alongside first party code? Do you store the dependencies in your repository at all, or push them to something like a Maven artifact repository
— https://www.rocketpoweredjetpants.com/2017/11/organising-a-monorepo/
Checking in the binary artifacts has the disadvantage that source control tools are seldom optimised for storing binaries, so any changes will cause the overall size of the repository to grow (though not a snapshot at a single point in time) The advantage is that build times can be significantly shorter (as all that needs to be done is link the dependency in)
— https://www.rocketpoweredjetpants.com/2017/11/organising-a-monorepo/
Monorepo is a popular way of organizing code bases in large organizations like Google, Facebook and Twitter. You can also find many open source projects that use a single git repository to store and develop multiple sub-packages. Some examples are Babel and Laravel.
If you are not familiar with the term “monorepo”, check out this 5 min video from Fabien Potencier, creator of Symfony framework.
I personally have been using this technique for many years without knowing its name. The idea is very simple: you store your backend/ and frontend/ folders in one repository.
— https://systemseed.com/articles/automated-releases-in-a-cross-language-monorepo
If you cannot overhaul the directory structure of your entire repository, you should not entertain a monorepo