3 ms·
Mirroring only allows dependencies in one direction. Let's say package A is only in the monorepo and package B is mirrored into the monorepo. A can depend on so
by opportune 7y ago
Mirroring only allows dependencies in one direction. Let's say package A is only in the monorepo and package B is mirrored into the monorepo. A can depend on some snapshot of B, (of, say, a client library) but B can't depend on packages from A, because outside of the monorepo B has no knowledge of A.
Also, one main advantage of a monorepo is you can make changes across many packages at once. The canonical textbook example is changing the API of my service: I can find all the instances in the monorepo of where that API gets used and change both the API and update all the calling instances in an atomic operation. You can't (or at least, shouldn't) do that to mirrored projects because the mirror in the monorepo is downstream from the source of truth for the project.
- konschubert 7y agoIf you make backwards-incompatibilities API changes like this, you also need simultaneous/atomic deploys across all services. On the other hand, if you aren’t doing simultaneous/atomic deploys, then having a monorepo may actually be an obstruction.
- opportune 7y agoYeah, that's the part I left out because it does get complicated when it comes to releases. For simplicity's sake, let's say everything actually gets bundled into one binary and released together.
- yjftsjthsd-h 7y ago> bundled into one binary and released together. In fairness, that's the canonical test for "should this be 1 repo"
- lrem 7y agoNot always. Renaming a proto field is one common example.