I've been using monorepo for almost a decade, and I was thrilled with that. Yet, in recent years I've noticed a few glitches in the workflow. The more popular the package became, the more visible frictions were.
How do I see the monorepo approach in 2023, and what do I want to do differently?
For frameworks like Symfony, Laravel, or Laminas, the monorepo is the best choice. The packages like http, dependency injection, forms, or validator are very close to each other. Their cohesion is high = if we change, e.g., validator, we'll update the forms package too.
Monorepo makes it easy to release new major releases like the upcoming Laravel 10. Users of the framework appreciate that the whole upgrade is done in a single run.
In one project I've been working on, we were considered monorepo for applications. Imagine you have an e-commerce for T-shirts, another for selling cars, and another for rentals. You are a developer company and you maintain all of them. Why not put them in a single repository? That would save you time for upgrades, CI setup and make changes cheaper, right?
Yes, that's true. On the other hand, 3 domains are now leaking across the repository, the pull request to various projects clashes, and any significant change may leak to other projects. E.g., an upgrade to PHP 8.1 has to be done in sync.
Saying that, I'd definitely not recommend using a monorepo for projects.
Now we get to the only monorepo I maintain - the Symplify monorepo. You may know it from hits like Easy Coding Standard, Config Transformer, Monorepo Builder or Vendor Patches.
It contains about 30 packages and about 5 tools.
The monorepo is very convenient in situations we deal with code quality:
One commit and single pull request improve 30 packages at once. That's pretty smooth. At least for me as a maintainer.
But for you as a contributor or developer who uses compose require symplify/*, it gets a little bit dicey:
packages/easy-coding-standard - there are /src and more nested /packages directorysymplify/easy-coding-standard, it was closed instantly because that package was read-onlysymplify/symplify, it's somewhere elseThese problems have been here for at least the past 4 years, and I knew we must solve them. It helped me look at other packages - apart from frameworks, the packages are doing fine in their repositories.
"If you don't think you can run a marathon,
go to the end of your street."
After having monorepo for years, my thinking was very narrow-minded, and I was scared. I needed more information and genuine experience. I've decided to make a little experiment.
In November 2022, I started to separate Symplify packages into their repository. That way, I could see how it works and how the release and maintenance work.
This way, we've separated tools from the Symplify monorepo to their repositories:
I waited to announce this change for two months because I was curious how the community would react. There were no complaints. Quite the contrary - more people started to contribute fixes!
...and how is that for me?
Before, I had to load 30 packages in an IDE, and my mind had to be careful about the changes. Now I open the single package with a relaxing mind.
I've cleaned up the packages from useless mutual dependencies, made them smaller and more to the point.
I was taking the courage to write this post because I wrote about 5 posts that made monorepo like a silver bullet. Now it's time to share the experience and past mistakes - I know I've learned much from it, and I hope you have too.
Happy coding!
Do you learn from my contents or use open-souce packages like Rector every day?
Consider supporting it on GitHub Sponsors.
I'd really appreciate it!
