4 ms·

It depends. If you drop a library for internal usage only and you want to change the contract, and the tests, library, and api are all in the same repo, you ju

It depends. If you drop a library for internal usage only and you want to change the contract, and the tests, library, and api are all in the same repo, you just change them in a single PR and that's done. This works because the single commit hash contains all information. It requires people put their code in the monorepo and hookup their tests, but assuming they do, you can build a reasonable degree of confidence on a green build. Once you separate the library different repo, and let people consume that as something in their own repos, you need to do the versioning dance as you have no idea if their still is still working. A lot of people go for the latter because it contextually allows them to ignore the rest of the stack, and there are some pros to doing this, but testing, deploying, versioning, etc, all become more difficult, and that's something struggle with. Thus, unless you have a crap load of code / commits, monorepos arguably have more advantages than disadvantages.

bluGill 3y ago
If the same problem doesn't exist in a monorepo in a different form then your project is not large enough to be in this discussion in the first place.
- ownagefool 3y ago
  It's actually just trade offs that we should be able to have professional discussions about, otherwise your advocating for "always use a monorepo" unless your library is for public consumption. The reality is, at some point, having repos that are hundreds of GB with hundreds of active PRs also has its own downsides that requires tooling and workflows to combat. Meanwhile, splitting it all up introduces integration problems. It's definitely pick your poison, though specific requirements and circumstances make specific paths more or less potent.
  - bluGill 3y ago
    The problem is many people arguing for a mono repo feel like the size of their project means breaking into multiple repos mean put each function in a separate repository - which is obviously absurd. It is good if your project is that small, but you also are not facing the same pains as large projects are.

bluGill 3y ago

If the same problem doesn't exist in a monorepo in a different form then your project is not large enough to be in this discussion in the first place.

ownagefool 3y ago
It's actually just trade offs that we should be able to have professional discussions about, otherwise your advocating for "always use a monorepo" unless your library is for public consumption. The reality is, at some point, having repos that are hundreds of GB with hundreds of active PRs also has its own downsides that requires tooling and workflows to combat. Meanwhile, splitting it all up introduces integration problems. It's definitely pick your poison, though specific requirements and circumstances make specific paths more or less potent.
- bluGill 3y ago
  The problem is many people arguing for a mono repo feel like the size of their project means breaking into multiple repos mean put each function in a separate repository - which is obviously absurd. It is good if your project is that small, but you also are not facing the same pains as large projects are.