5 ms·

> Bugs can and will happen, eg. when A depends on B and some developer accidentally makes a change to B that will pass B's tests but only break in A's use case.

> Bugs can and will happen, eg. when A depends on B and some developer accidentally makes a change to B that will pass B's tests but only break in A's use case. In monorepo case such bug can be noticed before the broken code hits master. 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?

dezgeg 2y ago
> 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?
- ggregoryarms 2y ago
  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.

dezgeg 2y ago

> 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?

ggregoryarms 2y ago
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.