2 ms·
This is almost the only advantage. A related "advantage" is forced upgrades when dependencies change - since you can't have code depending on different versions
by barrkel 4y ago
This is almost the only advantage. A related "advantage" is forced upgrades when dependencies change - since you can't have code depending on different versions of in-repo libraries and services, client code needs to adapt or die.
The more clients a library or service has, the more expensive this is, and it's an ongoing maintenance cost for every client. Since people changing the service don't feel the full pain of this maintenance cost, changes keep on happening, and eventually clients get culled because it's too expensive to keep on maintaining them all.
From the outside, this looks like the company abandoning venerable but still working product, and makes people scratch their heads, wondering why.
- ithkuil 4y agoYou can have a monorepo without having all the modules share the dependencies. For example you can have multiple go.mod files in a single monorepo. People often conflate these two things because often teams actually want to have centralized dependencies (so that you're forced to update or die as you said). If that doesn't work for you you can choose to have modules (or groups of modules) keep their independent set of dependencies, all while keeping the code in the monorepo.