3 ms·
>Firstly, wishing to see how library changes will cause issues in downstream consumers is often a sign of very deep problems, because the library designer shoul
by treis 8y ago
>Firstly, wishing to see how library changes will cause issues in downstream consumers is often a sign of very deep problems, because the library designer should be free to make changes or enhancements as they deem necessary to solve the problems they need to solve, which may require validating new changes don’t introduce unexpected problems for consumers, but, critically, also may not involve that, and in fact the usual case should be that it doesn’t involve that.
One of my pet peeves is when another developer tells me something "should" happen. I know library changes should not cause unexpected problems. The question is does that library change cause unexpected problems. Which is one of the benefits of a monorepo. You can make a library change and with at least some level of backing say that it doesn't break anything.
>Instead, it’s up to consumers to consume versioned artifacts of the library (more on this in a moment), so that consumers are totally in control of “opting in” to new changes. If the consumer doesn’t want to opt in, they should not be forced to (e.g. in monorepos where a successful merge of library X is a silent, de facto upgrade for all consumers required to consume library X from the same commit, etc.)
>Instead, the consumer should be the one creating an experimental branch with the intended version upgrade, and running it through the consumer’s validation tests to see if opting to upgrade the version will work.
The problem is that in an enterprise you will have many things that aren't under active development. So if you rely on consumers to pin a version and then upgrade you might end up with dozens of different versions of a library out there. And then what happens if you find a security issue or something else that forces everyone to upgrade to the latest version? Suddenly you have a bunch of applications that no one has touched for a while that all need to be upgraded.
- mlthoughts2018 8y ago> “One of my pet peeves is when another developer tells me something "should" happen.” Exactly, like when someone tells you that you should upgrade your dependency simply because some new code was merged. > “So if you rely on consumers to pin a version and then upgrade you might end up with dozens of different versions of a library out there.” The same thing happens in a monorepo, usually with dozens of incompatible legacy bundles of feature flags / toggles.