3 ms·
> Shouldn't the person/team who makes a change take ownership of fixing any breakage it causes, rather than passing the buck to their customers? That doesn’t f
by cgrealy 5y ago
> Shouldn't the person/team who makes a change take ownership of fixing any breakage it causes, rather than passing the buck to their customers?
That doesn’t feel scalable to me. I’d imagine some dependencies at Google run to hundreds of clients.
To take an OSS view, some packages run to hundreds of thousands. Imagine if the maintainers of react had to fix all their clients.
- ratorx 5y agoWith React, it’s not possible because there’s no systematic way to change client code. With a monorepo, it’s more tractable. It’s still not scalable in the sense that the downstream can make any change they want. They are restricted to changes they can either manually or automatically apply to client code in a reasonable amount of time. But that’s the trade off for being a heavily depended on library (which a lot of the time is an explicit decision).
- cgrealy 5y ago> With a monorepo, it’s more tractable. Is it really though? Sure, it's technically possible, but it feels like a massive burden to place one on dependency. Not only do you have to maintain your own lib, but you have to understand how every other project uses it.
- account42 5y agoSounds like a very good motivation to keep breaking changes to an absolute minimum.