3 ms·

“You'd need a way to run all tests in all repos reflecting a new change.” You really shouldn’t have to run every test on every product. Or really any other rep

“You'd need a way to run all tests in all repos reflecting a new change.” You really shouldn’t have to run every test on every product. Or really any other repos. Use semantic versioning, pin your dependencies, don’t make breaking changes on patch or minor versions.

joshuamorton 8y ago
Pinning your dependencies is an antipattern (or at least in the eyes of many people who support monorepos it is). It results in one of three things: 1. People never update their dependencies. This is bad (consider a security issue in a dependency) 2. Client teams are forced to take on the work of updating due to breaking changes in their dependencies. If they don't, we're back at 1. 3. Library teams are forced to backport security updates to N versions that are used across the company. But really, the question to ask is >don’t make breaking changes on patch or minor versions How can you be sure you aren't breaking anyone without running their code? You can be sure you aren't violating your defined APIs, but unless you're perfect, your API isn't, and there are undocumented invariants that you may change. Those break your users. Monorepo says that that was your responsibility, and therefore its your job to help them fix it. Polyrepo says that you don't need to care about that, you can just semver major version bump and be done with it, upgrading be damned. No semver means that you, not your users, feel the pain of making breaking changes. That's invariably a good thing.
- senderista 8y ago
  At AMZN, which has 1000s of separate repos, 1) was the general case, with 2) occurring whenever there was a critical security issue in some library that no one had updated for years. The resulting fire drill of beating transitive dependencies into submission could occupy days or weeks of dev time.
titanomachy 8y ago
When you change a project, you have to test the effect of your changes on downstream dependencies. Semver is wishful tthinking. Even a change that _you_ think is non-breaking could break something. Saying "well the downstream team was using undocumented behaviour so it's their fault" doesn't really hold much water when your team is Driving Directions and the downstream team is Google Maps Frontend and your change caused a production outage.

joshuamorton 8y ago

Pinning your dependencies is an antipattern (or at least in the eyes of many people who support monorepos it is). It results in one of three things: 1. People never update their dependencies. This is bad (consider a security issue in a dependency) 2. Client teams are forced to take on the work of updating due to breaking changes in their dependencies. If they don't, we're back at 1. 3. Library teams are forced to backport security updates to N versions that are used across the company. But really, the question to ask is >don’t make breaking changes on patch or minor versions How can you be sure you aren't breaking anyone without running their code? You can be sure you aren't violating your defined APIs, but unless you're perfect, your API isn't, and there are undocumented invariants that you may change. Those break your users. Monorepo says that that was your responsibility, and therefore its your job to help them fix it. Polyrepo says that you don't need to care about that, you can just semver major version bump and be done with it, upgrading be damned. No semver means that you, not your users, feel the pain of making breaking changes. That's invariably a good thing.

senderista 8y ago
At AMZN, which has 1000s of separate repos, 1) was the general case, with 2) occurring whenever there was a critical security issue in some library that no one had updated for years. The resulting fire drill of beating transitive dependencies into submission could occupy days or weeks of dev time.

titanomachy 8y ago

When you change a project, you have to test the effect of your changes on downstream dependencies. Semver is wishful tthinking. Even a change that _you_ think is non-breaking could break something. Saying "well the downstream team was using undocumented behaviour so it's their fault" doesn't really hold much water when your team is Driving Directions and the downstream team is Google Maps Frontend and your change caused a production outage.