←back to thread

If all the world were a monorepo

(jtibs.substack.com)
176 points sebg | 4 comments | 16 Sep 25 08:33 UTC | HN request time: 0.815s | 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 #
skybrian ◴[20 Sep 25 04:48 UTC] No.45310479[source]▶
Yes, it's nice when you can update arbitrarily distant files in a single commit. But when an API is popular enough to be used by dozens of independent projects, this is no longer practical. Even in a monorepo, you'll still need to break it up, adding the new API, gradually migrating the usages, and then deleting the old API.
replies(1): >>45310810 #
1. vasvir ◴[20 Sep 25 05:57 UTC] No.45310810[source]▶
Yes,

Also the other problem of a big monorepo is that nothing ever dies. Let's say you have a library and there are 1000 client programs or other libraries of your API. Some of them are pretty popular and some of them are fringe.

However when you are changing the API they all have the same weight. You have to fix them all. In the non monorepo case the fringe clients will eventually die or their maintainer will invest on them and update them. It's like capitalism vs communism with central planning and all.

replies(1): >>45311165 #
2. malkia ◴[20 Sep 25 07:08 UTC] No.45311165[source]▶
If the monorepo is build and tested by single build system (bazel, buck, etc.), then it can graph leaf dependencies with no users. For example library + tests, but no one using it (granted it might be something new popping out, still in early development).

Bazel has the concept of visibility where while you are developing something in the tree, you may explicitly say who can use it (like trial version).

But the point is, if something is build, it must be tested, and coverage should catch what is build, but not tested, but also should catch what is build and tested but not really used a lot.

But why remove it, if it takes no time to build & test (?), and if it takes more time to test, it's usually on your team to start your own testing env, and not rely on the general presubmit/preflight one, and because since the last capacity planning you have only that amount of budget, you'll soon realize - do we really need this piece of code & the tests?

I mean it's not perfect, there would be always something churning using time & money, but until it's pretty big problem it won't go away automatically (yet)

replies(1): >>45311995 #
3. gmueckl ◴[20 Sep 25 10:12 UTC] No.45311995[source]▶
Dead cose in a huge monorwpo is more costly than just build and test time. It's also noise when searching through code. One thing to realize is that deleting dead code from the tree doesn't destroy anything because it's still in the repo history and can be restored from there.
replies(1): >>45312532 #
4. yorwba ◴[20 Sep 25 11:53 UTC] No.45312532{3}[source]▶
Hence why Google has Sensenmann to reap dead code: https://testing.googleblog.com/2023/04/sensenmann-code-delet...