←back to thread

If all the world were a monorepo

(jtibs.substack.com)
202 points sebg | 4 comments | 16 Sep 25 08:33 UTC | HN request time: 0s | source
Show context
derefr ◴[20 Sep 25 02:14 UTC] No.45309542[source]▶
CRAN’s approach here sounds like it has all the disadvantages of a monorepo without any of the advantages.

In a true monorepo — the one for the FreeBSD base system, say — if you make a PR that updates some low-level code, then the expectation is that you 1. compile the tree and run all the tests (so far so good), 2. update the high-level code so the tests pass (hmm), and 3. include those updates in your PR. In a true centralized monorepo, a single atomic commit can affect vertical-slice change through a dependency and all of its transitive dependents.

I don’t know what the equivalent would be in distributed “meta-monorepo” development ala CRAN, but it’s not what they’re currently doing.

(One hypothetical approach I could imagine, is that a dependency major-version release of a package can ship with AST-rewriting-algorithm code migrations, which automatically push both “dependency-computed” PRs to the dependents’ repos, while also pushing those same patches as temporary forced overlays onto releases of dependent packages until such time as the related PRs get merged. So your dependents’ tests still have to pass before you can release your package — but you can iteratively update things on your end until those tests do pass, and then trigger a simultaneous release of your package and your dependent packages. It’s then in your dependents’ court to modify + merge your PR to undo the forced overlay, asynchronously, as they wish.)

replies(5): >>45309883 #>>45310322 #>>45310479 #>>45310852 #>>45312230 #
1. boris ◴[20 Sep 25 06:06 UTC] No.45310852[source]▶
There is a parallel with database transactions: it's great if you can do everything in a single database/transaction (atomic monorepo commit). But that only scales so far (on both dimensions: single database and single transaction). You can try distributed transactions (multiple coordinated commits) but that also has limits. The next step is eventual consistency, which would be equivalent to releasing a new version of the component while preserving the old one and with dependents eventually migrating to it at their own pace.
replies(1): >>45311313 #
2. awesome_dude ◴[20 Sep 25 07:41 UTC] No.45311313[source]▶
Doesn't that rely on the code being able to work in both states?

I mean, to use a different metaphor, an incremental rollout is all fine and dandy until the old code discovers that it cannot work with the state generated by the new code.

replies(2): >>45311650 #>>45312980 #
3. immibis ◴[20 Sep 25 08:59 UTC] No.45311650[source]▶
Yes, it does.
4. stetrain ◴[20 Sep 25 12:53 UTC] No.45312980[source]▶
Yes, but depending on the code you’re working on that may be the case anyway even with a monorepo.

For example a web api that talks to a database but is deployed with more than one instance that will get rolling updates to the new version to avoid any downtime. There will be overlapping requests to both old and new code at the same time.

Or if you want to do a trial deployment of the new version to 10% of traffic for some period of time.

Or if it’s a mobile or desktop installed app that talks to a server where you have to handle people using the previous version well after you’ve rolled out an update.