|
|
|
|
|
|
by pricechild
2437 days ago
|
|
|
> 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. |
|
|
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.