> I don't see what point you tried to make. So A breaks when someone breaks B. That's ok. You spot the error the moment you try to update A, well before you commit any code. You file a low-priority ticket and go on with your life because A is still good in production.
What inevitably happens is that A hasn't been updating their version of B in weeks/months, but some recently landed bug fix in B is now needed RightAway(tm). And now if something accidental breakage happened between now and weeks/months ago, it'll be much more annoying to triage.
> Not really, it's the easiest part of the whole thing and a non-issue. If you manage a package this does not even register as a problem.
Well, where I'm at we have semi-regularly teams we have never heard of using our libraries. How can I know what things such people are using?
Re:Monorepo – Our Experience
by ggregoryarms on Thursday November 07, 2024 @04:29PM
(#42081269)
At least you're in control of when to look at the updates in new versions.
A monorepo gives you less control. If you're unable to enforce control through other means, sure use a monorepo. But it's limiting.
I don't see what point you tried to make. So A breaks when someone breaks B. That's ok. You spot the error the moment you try to update A, well before you commit any code. You file a low-priority ticket and go on with your life because A is still good in production.
> Knowing when no one uses older versions is also hard (...)
Not really, it's the easiest part of the whole thing and a non-issue. If you manage a package this does not even register as a problem. If it's a service you have request metrics.
What is the problem, really?