Motivation

Hi, I'm Anthony and I wanted to take a quick moment to tell you why I created this resource. There are several reasons that I'll list here in no particular order.

Monorepos are a better way to build software

If you know me well enough, it's extremely rare that I speak in absolutes. But this is a principle that I'll stand by much more closely than nearly all of my other software opinions.

Handling the responsiblities of Turbo DX at Vercel, I get to work with individuals, startups, and enterprises that are trying to ship their products quickly, safely, and with high-performance.

To put it simply, I've consistently watched monorepos outperform any other CI/CD, code organization, and deployment strategy. In the past, monorepo tooling wasn't good enough to keep pace with developers. But, today, the tooling is catching up and the results are showing.

Does this mean a monorepo is a golden bullet in any and all cases? No, probably not. But I'd say it's the 90% case.

The Chosen One

There are many resources out there talking about monorepos - but it's hard to get all of the information in one place.

Sometimes, they'll tell you why you should use monorepo, leaving you to figure out how to create and implement the details.

Sometimes, they'll describe an incredibly in-depth specific technical problem and solution set - but what about the rest of your repo?

Sometimes, they'll simply link you to sets of opaque documentation that don't really help you all that much unless you already have several layers of existing knowledge.

I want Maestros to be The Chosen One. A place where we have everything we need to create healthy repositories that ship. We'll mix fundamental knowledge with links to specific pieces of documentation and then build a practical example.

Monorepos are misunderstood

Despite being (what I think is) a better way to work, I find that there's a lot of opportunity out there for folks to have a better understanding of monorepos. Often, folks don't realize that a monorepo really is a great option for their use case.

I think this goes back to the previous point. With better resources available, we can unlock better workflows in our monorepos and ship better.

You need it

If you're like me, you've looked for am opinionated resource about how to build a monorepo from the ground up and...well, didn't find one. Monorepo Maestros is for you.

I need it

I'll be real with you: I was finding myself making the same explanations over and over again. Whether it was "How do I ESLint?" all the way to incredibly specific enterprise use cases, I love helping people with their monorepos.

But I want to be more effective with my time. Instead of writing the explanation many times whenever the question comes up, I can write it once and point people here. And, hopefully, I'll be able to iterate on my