Splitting monorepo is a trivial operation of getting some code to some repository. Unless your take into rocket science like Symplify does. It is slow, complicated, and doesn't work on GitHub, where the open-source lives.
Symplify/MonorepoBuilder is easy to set up and easy to use:
But the split operation itself is not really Usain Bolt among instant feedbacks:
"...symplify/monorepo-builder ... takes ~20 minutes to go through and roll out all packages, one by one"
As for Symplify, if we merge pull-request, it takes ~8 minutes to use the code. It takes ~4 minutes of waiting for Travis to notice, then 3 minutes to split ~15 packages, and 1 minute to trigger Packagist.
Found a typo in the return type? Commit and... wait 8 minutes. That is bad and breaks the flow and your productivity.
A typical solution for such performance issues is running it in parallel processes. The speed gain is x-times, where
x is the number of CPUs your machine has.
vendor/bin/monorepo-builder split --max-processes 6
Before we added parallel run, it took over 7 minutes on just 8 packages!
What is a monorepo split?
That's it! Nothing fancy, nothing that needs an MIT degree. Still, the Symplify implementation includes these layers:
Why keep it simple, right?
Thanks to previous Inception-complexity, the code can break in any of these layers. From git to invalid bash syntax to a tool that wraps the Git API in PHP or typo in the target directory.
In reality, you get something like this:
I do appreciate a good error message.
If you want to make it work on your monorepo, you have to follow these steps:
The vendor-lock on 2 services - GitHub and Travis - might be do-able for open-source maintainers. But if you just want to start with monorepo, learning 2 services at once is a killer.
There is no need for that. And yes, there is a better way to handle automated monorepo split. I'll show you in the next post.