[pricechild]

I regularly join projects where someone has decided to place the project's code in half a dozen different repositories.

Even though it's one project.

Even though they refuse to allow a release of a single component - it must all be released together without forwards/backwards compatibility.

I think most of of the time, the mono/multi debate is spoiled by people who feel they can have their cake and eat it too.

[megous]

I think that whether to use mono/multi repo depends on whether you're willing to dump money into updating everyting at once, or not. If not, monorepos are really a big hindrance. It's better to split on the project boundary (things that may have different development paces), and use git worktree for having different versions of libraries checked out for building/bundling.

It works fairly nicely with meson, as you can simply checkout a worktree of a library into a subprojects directory, and let individual projects move at their own paces even if you don't do releases for the libraries/common code.

It's not really clear why having to update every consumer in sync with library changes is beneficial. Some consumers might have been just experiments, or one off projects, that don't have that much ongoing value to constantly port them to new versions of the common code. But you may still want to get back to them in the future, and want to be able to build them at any time.

It's just easier to manage all this with individual repos.

[pricechild]

> whether you're willing to dump money into updating everyting at once

I think the majority of projects in this world only update everything at once. They haven't investing in testing, sensible api's and testing to allow updating small pieces of their solution.

From my experience, I also think the majority of people who think they have a library and need multi repos to deal with that, don't have a library.

To further clarify, one user of your library means you could stop pretending you have a library and avoid the pain.

I don't mean to insist these problems do not exist, I simply don't think many people have them.

[megous]

Project != company. Project != consultancy.

Monorepo just didn't work for me. I have ~10 web projects for different customers + my personal projects that use various versions of some common code.

It doesn't make any financial sense to evolve my common code by updating all the customer's code for free when they're not even asking for it. So on this level it doesn't work.

Even within a single company with just two devs and around 90 repos for the main product and plugins, it was hard to justify making a mono-repo with plain git, because plugins and the main app had different release schedules, priorities, so it never really happened that it was economical to port all plugins right away to the new version of the main app on every change.

I still think going multi vs mono is a business decision, rather than a technical one. You'll have to have special tooling for either case, just a different one.

[pricechild]

Yep, I agree and that all makes sense.

Don't you find those projects within the company wanting multi-repos also?

[megous]

They have multi-repos. There was some thought given to an idea to transition to mono-repo, but it never happened.