4 ms·

that stood out to me too... not the monorepo really, but the fact its a monorepo of a billion lines of code. seems almost impossible to maintain when you have a

that stood out to me too... not the monorepo really, but the fact its a monorepo of a billion lines of code. seems almost impossible to maintain when you have a dependency change at the lowest levels that affects numerous projects.If i am understanding google was in a situation where they had to update every project that used typescript inside the entire company at the same time, that seems untenable.

larzang 7y ago
Whether it's a monorepo or not doesn't change the fact that you have a billion lines of code to maintain, but at least this way they're forced to make changes consistently. The alternative would be doing it piecemeal with a dozen versions of dependencies propagating due to fragmentation, which is way way worse.
yoz-y 7y ago
Mostly it means that you have to be really thoughtful when introducing a breaking change to a low level library.
- papln 7y ago
  Or you can YOLO / Leroy Jenkins the change and let everyone else fix the breakage you create, or see if they demand a rollback.
  - yoz-y 7y ago
    They will not only demand a rollback but also do it. Besides, low level changes at this scale require a copious amount of approvals.
forgot-my-pw 7y ago
Here's an article from a maintainer of a framework library (Angular): https://medium.com/@Jakeherringbone/you-too-can-love-the-monorepo-d95d1d6fcebe https://medium.com/@Jakeherringbone/you-too-can-love-the-mon... Something like this might only be possible due to their tooling and test coverage. So when you change something, you immediately get alerted of broken tests.