Symplify Monorepo Builder Split - Fractal of Bad Design

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.

1. It's Super Slow

Symplify/MonorepoBuilder is easy to set up and easy to use:

vendor/bin/monorepo split

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.

2. It's so Slow, Despite having Parallel Run

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!

3. It's Rocket Science at it's Worst

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?

4. It has The Worst Error Message Output

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.

5. It Depends on both Travis and GitHub

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.

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!