4 ms·

I'm sure there are better arguments for a monorepo because I disagree with all 4 of the OPs ones: > Single source of truth This has never been a problem for m

I'm sure there are better arguments for a monorepo because I disagree with all 4 of the OPs ones: > Single source of truth This has never been a problem for me. You have an app in one repo depending on a version of a package built from another. I don't see the problem. > Visible cost of change Altering code does NOT require you to make sure everything is updated or compatible, only if you make a breaking change that the compiler can see or you affect a test that will fail after your change. There are lots of changes you can make that the monorepo doesn't detect any more than a multi-repo > Sharing and reusing code I don't agree that finding existing functionality to reuse is easier. How so? You search for "Tokenize" and hope to find something relevant? It is honestly no harder for me than looking into shared libraries or other packages. > Improved collaboration "Aligning repos". Not an issue as mentioned earlier. "Change the code and get proper reviews", this is nothing to do with monorepos. So sorry, I am not personally convinced that many orgs would benefit from monorepos unless they have the skill or cash to pay for the maintenance, the much larger testing requirements, the ability to unblock an organisation when one numpty has broken something or the fact that a load of projects get up-versioned all the time because one change was made to one thing, and this article did not convince me any more.

efficientsticks 5y ago
In a past job, minimising Pull Requests was a key motivator - you can touch a larger cross section of codebase with a single branch. It’s useful when lots of things that are genuinely distinct happen to have similar config, for example.
laurent123456 5y ago
I think the biggest argument in favour of monorepos is that both code and dependencies are version controlled. You can check out any commit and get a fully working environment, knowing that each module will be at the right version that's compatible with the other modules. Without this, you need to have some infrastructure to handle these dependencies, for example by agreeing on version numbers, making sure dependency versions of all modules in all repositories are correctly updated, etc. Maybe also scripts to rollback everything to a different versions. There are tools for this of course, but the nice thing with a monorepo is that it's built-in - it's all in the commit history. So when you say the org needs cash and skills for monorepo maintenance, I actually think it's the other way around. I've seen companies splitting each module in its own repository, but with no tooling to get dependencies right, and the whole thing was a mess. You can't know what commit of what repo is compatible with another commit of a different repo. Had they used a monorepo they wouldn't have this problem, because a commit either build or not, there's no unknown dependencies.
victorNicollet 5y ago
You have found a local optimum that involves multiple repos. Others have found a local optimum that involves a single repo. Arguments for mono-repos are not arguments against multi-repos. For some background: we migrated from multi-repo to mono-repo to solve several pain points, which are touched on in TFA. It's fair for you to state that you have never had a problem, or that you don't see it, but don't conclude that no one else has ever had that problem, or that they, unlike you, consider that problem to be important enough to need a solution. > [Single source of truth] has never been a problem for me. You have an app in one repo depending on a version of a package built from another. But I don't have a package built from another. To support multiple repos, do I need to configure package creation, set up an artifact server, and teach the team how to use a locally-built package for debugging/prototypes ? > There are lots of changes you can make that the monorepo doesn't detect any more than a multi-repo There are several techniques for working on a large codebase that involve making easy-to-detect changes, that can then followed to both explore the extent of what the work should cover, and ensure that no piece is forgotten. Having a monorepo makes it easier to put all the code in one place for the static analysis tools to crunch through. > I don't agree that finding existing functionality to reuse is easier. How so? You search for "Tokenize" and hope to find something relevant? You can "Find all references" of a specific type to identify functions that can operate on it. The list will usually be short enough to scan in a minute or two. If you're looking for a function to frobnicate that type, it will almost certainly be in the list. I'm not sure how you would this on packages from several repos (especially if that function is non-public). > "Change the code and get proper reviews", this is nothing to do with monorepos. My current tooling does not allow me to submit a PR that pushes two different commits to two different repos. If using packages to share code between repos, it also means that the change must deal with package versioning. There exists a set of tools, techniques and never-been-a-problems that can make mono-repo work and be productive, just like there exists a set of tools, techniques and never-been-a-problems that can do the same for multi-repos.

efficientsticks 5y ago

In a past job, minimising Pull Requests was a key motivator - you can touch a larger cross section of codebase with a single branch. It’s useful when lots of things that are genuinely distinct happen to have similar config, for example.

laurent123456 5y ago

I think the biggest argument in favour of monorepos is that both code and dependencies are version controlled. You can check out any commit and get a fully working environment, knowing that each module will be at the right version that's compatible with the other modules. Without this, you need to have some infrastructure to handle these dependencies, for example by agreeing on version numbers, making sure dependency versions of all modules in all repositories are correctly updated, etc. Maybe also scripts to rollback everything to a different versions. There are tools for this of course, but the nice thing with a monorepo is that it's built-in - it's all in the commit history. So when you say the org needs cash and skills for monorepo maintenance, I actually think it's the other way around. I've seen companies splitting each module in its own repository, but with no tooling to get dependencies right, and the whole thing was a mess. You can't know what commit of what repo is compatible with another commit of a different repo. Had they used a monorepo they wouldn't have this problem, because a commit either build or not, there's no unknown dependencies.

victorNicollet 5y ago

You have found a local optimum that involves multiple repos. Others have found a local optimum that involves a single repo. Arguments for mono-repos are not arguments against multi-repos. For some background: we migrated from multi-repo to mono-repo to solve several pain points, which are touched on in TFA. It's fair for you to state that you have never had a problem, or that you don't see it, but don't conclude that no one else has ever had that problem, or that they, unlike you, consider that problem to be important enough to need a solution. > [Single source of truth] has never been a problem for me. You have an app in one repo depending on a version of a package built from another. But I don't have a package built from another. To support multiple repos, do I need to configure package creation, set up an artifact server, and teach the team how to use a locally-built package for debugging/prototypes ? > There are lots of changes you can make that the monorepo doesn't detect any more than a multi-repo There are several techniques for working on a large codebase that involve making easy-to-detect changes, that can then followed to both explore the extent of what the work should cover, and ensure that no piece is forgotten. Having a monorepo makes it easier to put all the code in one place for the static analysis tools to crunch through. > I don't agree that finding existing functionality to reuse is easier. How so? You search for "Tokenize" and hope to find something relevant? You can "Find all references" of a specific type to identify functions that can operate on it. The list will usually be short enough to scan in a minute or two. If you're looking for a function to frobnicate that type, it will almost certainly be in the list. I'm not sure how you would this on packages from several repos (especially if that function is non-public). > "Change the code and get proper reviews", this is nothing to do with monorepos. My current tooling does not allow me to submit a PR that pushes two different commits to two different repos. If using packages to share code between repos, it also means that the change must deal with package versioning. There exists a set of tools, techniques and never-been-a-problems that can make mono-repo work and be productive, just like there exists a set of tools, techniques and never-been-a-problems that can do the same for multi-repos.