Dev Discussions: Everything You Need to Know about Monorepos with Juri Strumpflohner of Nrwl

kennyray212

Ken Swearengen

Posted on July 13, 2022

Dev Discussions: Everything You Need to Know about Monorepos with Juri Strumpflohner of Nrwl

As the Director of Developer Experience for Nrwl (pronounced “narwhal,” like the sea creature), Juri Strumpflohner knows a thing or two about monorepos.

Nrwl is the company behind Nx, perhaps the most popular monorepo management tool. Juri’s job is to ensure developers like you have the best possible experience using Nx.

If you’ve never heard the term monorepo, you’ll want to pay close attention to this post. Monorepos have become increasingly popular as organizations look for more efficient ways to manage and collaborate with their code bases.

At its simplest, a monorepo is a repository that contains all aspects of an organization’s code base – different projects, applications, and libraries all live together in the same repo. This is in contrast to a polyrepo, where everything lives in its own separate repository:

Top image is labeled "monorepo" and has "org 1" at the top with lines drawn from this box to boxes labeled app 1, lib 1, app 2, lib 3, and lib 2. the send image below that is labeled "polyrepo" and has a circle in the middle labelled "library repo" with other circles labelled app 4 repo, app 1 repo, app 2 repo, app 3 repo, and app 2 repo all pointing towards the library repo circle in the center.Via monorepo.tools

Pioneered by tech giants like Google and Meta with tools like Bazel and Buck, monorepos are seeing widespread adoption across companies of all sizes and industries.

CoderPad Developer Advocate Corbin Crutchley recently sat down with Juri to discuss what it is about monorepos that are making them so popular – and possibly heading to a code base near you.

Monorepos – more than just a single repo

While the word monorepo comes from mono-repository, the term itself can be misleading.

Yes, one of the defining features of a monorepo is that two or more applications or libraries reside within the same repository or workspace.

But that alone doesn’t make a monorepo – it makes it a messy monolithic repository that generates more problems than it solves.

A good monorepo is defined by the relationships and connections between the components of the repository.

This means that the relationships the development teams would build outside their repository – between applications, libraries, configuration files, etc. – are instead built inside a single repository. Each component has ready access to the other members within the repository.

Compare this to the more traditional polyrepo, where each application and library has its own repository. To connect, they have to pull packages from the outside using something like node package manager (npm) registries.

ℹ️ Despite the name, most companies don’t have just one repository for the entire company. Many large enterprises will have a few monorepos, each dedicated to a particular domain or department. The key is that within these monorepos, the barrier to collaboration is lower than it would be in a polyrepo.

You can now start to see some of the benefits of monorepos:

  • Since everything is accessible to everything else, all applications have access to the same libraries. That means you’re drastically reducing the amount of redundant code.
  • You only need one Continuous Integration/Continuous Delivery process, as opposed to one for every repository.
  • It’s easier to catch dependency errors. Since everything is integrated into the same build, the monorepo build tool will catch any downstream errors resulting from the change during compilation rather than when the dependent application or library consumes the change.

Often, companies will start building out their monorepo management process themselves. After all, it’s simple enough to throw a couple of applications and libraries into a repository and write the scripts to link them.

But scaling them can be a whole other issue. As the monorepo grows, builds take longer. Testing slows down as you wait 20, 30, or 40 minutes for the build to finish. So developers start throwing changes into every build, so they don’t have to wait for the next one, which adds more code to the build, which slows it down even more – you get the picture.

That’s where tools like Nrwl’s Nx come in.

How a monorepo management tool boosts your performance

While you could spend significant development effort creating scripts for managing your monorepo builds, it may be easier to stick with a monorepo tool like Nx or Lerna.

Nrwl, in collaboration with other major monorepo management tools, has put together a great website documenting the features of these tools. Among the more notable features that monorepo tools have to offer:

Detecting downstream changes

Many management tools will automatically detect what changes were made and any downstream dependencies on those changes.

Not only is this a much more efficient way to process your builds, but you also don’t have to worry about breaking any dependencies because you forgot to update it when you pushed your changes.

Restricting access

In many monorepo management tools, you can utilize code owner files to restrict access to different projects within your monorepo.

If you’re using a folder structure to reflect the different domains and libraries within your project, you can easily apply permissions to the various folders to control project access. These folder restrictions are usually enforced by CI/CD using a runner like GitHub actions.

Task scheduling

Perhaps the most ubiquitous feature of monorepo management tools is their ability to schedule build tasks. This allows you to control what gets built and when (i.e., sequentially, in parallel, etc.) to ensure your application and libraries are built efficiently and error-free.

Code generation

Some monorepo tools, like Nx, contain plugins and integrations that make code generation much more effortless.

You can use these plugins to create a basic app structure (like what you’d get with the npx create-react-app command) or set up testing. With these plugins, you can customize the code generation to create the code for your particular use case.

Consistent tooling

One of the most significant benefits of utilizing a monorepo management tool is that the same tools are used across all projects in the repository. So instead of balancing three different contracts and hiring a DevOps specialist for each tool, you just have to worry about paying for and managing one toolset.

You also keep redundant utilities and tools to a minimum. Since the different parts of your repo are connected, you can easily share things like types or libraries between your front and back end.

What’s next for monorepos

If you’re interested in following the development of a specific monorepo management tool, monorepo.tools is an excellent place to start. There you can find a list of seven of the most popular monorepo tools, along with the contact information for developers for each of those tools.

As for Nrwl, Juri mentioned that they recently just took over stewardship of Lerna.js, a popular open-source monorepo management tool. He hopes to have Lerna supplement a lot of Nx’s functionality.

For example, Nx helps ensure different components in your repository link together nicely and that the tool creates a great developer experience for managing your monorepos. When you combine this with Lerna’s great versioning features, you have a powerful management tool.


Interested in more conversations with developers about their tech stacks? Checkout these other Dev Discussions:

💖 💪 🙅 🚩
kennyray212
Ken Swearengen

Posted on July 13, 2022

Join Our Newsletter. No Spam, Only the good stuff.

Sign up to receive the latest update from our blog.

Related