Everything you need to know about monorepos

Related:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=30424279" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=30424279</a><p>&quot;Ask HN: Is there any way to detect websites that are SEO-optimized on Google?&quot;<p>Unfortunately, those seem to even get into HN. This page is a perfect example. This is how the page starts:<p><pre><code> Everything you need to know about monorepos, and the tools to build them. Understanding Monorepos Monorepos are hot right now, especially among Web developers. We created this resource to help developers understand what monorepos are, what benefitsthey can bring, and the tools available to make monorepo development delightful. There are many great monorepo tools, built by great teams, with different philosophies... </code></pre> I got so tired at this point that I stopped reading.<p>In my mind, I see the job description on Fiverr &quot;Fast SEO writer wanted! Please write a 3000 word page about monorepos. Make sure to mention &#x27;monorepos&#x27; and related terms like &#x27;web developers&#x27;, &#x27;tools&#x27;, &#x27;development&#x27; etc frequently.&quot;

There should be a big warning on the top:<p>Monorepo is a way to morph dependency management problem into source control problem within your organization. Currently, FOSS tools solve none of them.

When I talk about monorepos in our company, I always try to make the distinction between JS monorepo tooling (say nx, turbo or more low-level pnpm&#x2F;npm&#x2F;yarn workspaces) and real (?) monorepo tooling (say Bazel). Whereas the latter has more focus on dealing with a wide variety of source code types and artifacts the former is exclusively dealing with NPM packages (which may include other stuff like Go&#x2F;Rust sometimes). Does this distinction even make sense?

Title should reflect what the website has used, &quot;Monorepo explained&quot;. It certainly doesn&#x27;t cover &quot;everything you need to know about monorepos&quot; and glosses over its disadvantages and the things you need to watch out for.<p>The most important one being that you need to have an org&#x2F;team structure that is set up to support it. You cannot say that it will make the org more efficient as organizations are not all the same. In order to push monorepos, the decision makers ought to know what those caveats and tradeoffs are, or they&#x27;re going to be in for a sad time.<p>Site does do a good job of going over the tooling around it. Now this might be a matter of perception, it seems that the tooling is getting better, though not yet very mature. I see a few instances of &quot;write your own&quot; where the tooling is lacking, which is not a great way to go about things, and once again, makes assumptions about the nature of the orgs.

Something very important not covered by the article:<p>Is the tool going to help me detect when I accidentally bypass the declared dependencies?<p>For example, in a basic monorepo it&#x27;s very easy to accidentally rely on the file layout on disk (require&#x27;ing a dependency not in your package.json but that has been hoisted because it&#x27;s a dependency of a different package accidentally succeeds, cp&#x27;ing files from `..&#x2F;some-other-project` should not be allowed but is possible). All of these invalidate some optimizations that monorepo tools want to make.<p>At scale with many contributors, it&#x27;s HARD to teach and remember and apply all these rules, and so the monorepo tool really should help you detect and fix them (basically: fail the build if you mess up).<p>The article doesn&#x27;t really make it clear which tools will do that for you. Pretty sure that Bazel does, Nx probably does, and lerna and turborepo don&#x27;t.

I&#x27;m building a pretty big service that has four user-facing websites and even more backends (HTTP servers, highly bespoke job queues to run ML workloads, etc.)<p>This was an absolute nightmare to try managing in separate repos. I&#x27;ve finally settled on two monorepos: a Yarn&#x2F;TypeScript&#x2F;React frontend monorepo, and a Rust&#x2F;Docker backend monorepo.<p>Does anyone have any advice on these? I sort of stumbled into this pattern on my own and haven&#x27;t optimized any of it yet.<p>For Rust, I&#x27;m curious if folks have used Bazel for true monorepo build optimization. I don&#x27;t want to rebuild the world on every push to master.<p>Likewise for the frontend, is there any way to not trigger Netlify builds for all projects if only one project (or its dependencies) change?<p>Would super appreciate any advice.

The way this is written sets off my bs detectors that were built from the eras of &quot;serverless solves everything&quot; and &quot;mvc solves everything.&quot;<p>The only thing I&#x27;m convinced of these days is: whatever way you choose is the right way.

I wish they explained how to merge existing repos into one new (mono)repo while keeping git history. Still haven’t cracked that problem

Great information. I&#x27;ve been building a monorepo of my own for a system that consists of RESTful and event-driven microservices. They are defined via Open API and Async API respectively. Does anyone know a tool to generate documentations for each type of service and put them together into one cohesive documentation?

When you use monorepo to solve one problem, you have two problems to solve.

This is website is amazing. It&#x27;s doing a very needed job in the internet. I feel it should also be the trunkbaseddevelopment.tools and pairprogramming.tools :)