When to use Nx or Turborepo?

Right now, if we need to set up a new monerepo, we always have a question in mind. Nx or Turborepo?

Both are excellent for managing your monorepo; now let’s see the difference between the two of them.

Let’s start with Turborepo, the new trending monorepo orchestra created by Jared Palmer. Focused on high-performance and really easy to you use. You can find more information about it on his website.

Let's get started by copying and pasting this command into your terminal.

npx create-turbo@latest

You should have something like this:

As you can see, Turborepo has a local caching system. You can also use remote caching; documentation is available at the following link.

If we take a closer look, you can see that Turborepo is already adding two next.js applications in the apps folder, and three libs in the package folder as quick-starter.

You can simply start the two applications by running

npm run dev

which will run this command turbo run dev --parallel.

Turborepo will run the script dev in each package.json of the two next.js apps. It's really cool, because if you add a new folder in the app folder with a package.json and a new scrip,t dev Turborepo will also run it. So, you can easily add a new application of a different type. You just need a dev script to run it like the others.

All of that is managed with the file turbo.json that you can find in the root folder. With the following screenshot, you will see the default config generated with it.

As you can see, its name is a pipeline. You will find the documentation about it here.

Now you know how to add a new app, but what about the different libs. If you take a look at the package.json of the tsconfig lib, you will see something like this:

Now, how is it used? If you check the package.json of the web folder you will see this:

In dev dependency  you can see the tsconfig lib with a * as version. With that you can now simply use that library in the app and Turborepo will handle everything. Below you can find an example in the tsconfig.json of the web application.

So now that we did a little tour of Turborepo, let's do the same with Nx.

Before Turborepo, Nx was the default orchestrator that I would have used to manage a monorepo. It is designed to make and maintain production-ready applications as easily as possible.

You can also simply start by running this command

npx create-nx-workspace

You will need to answer some questions like with Turborepo, and select a template

I took next.js as a template to do this comparison. After finishing the setup with this template, Nx generated two applications. One is the real next application and the other one is to create some e2e tests for the main app. You also have one ui library generated directly.

If you want to add a new application or library,  you need to use one of their plugins. For example, if you want to add a new next.js application you can use the following command

npx nx g @nrwl/next:app my-new-app

You can do a lot of other things with the plugins; like creating a storybook, express app, etc. You can check the documentation here.

How can you use a library now? Nx is based on the tsconfig paths so if you check the root tsconfig you will see something like this:

So, if you want to use the UI library you can simply import @nx-demo/ui in your application and Nx will manage the rest for you.

With Nx you have a lot of cool features like this command;

npx nx migrate latest

Which helps you to update Nx and its plugins.

Both are fantastic, and at Mirahi, we are grateful to have those cans of packages to help us speed up and facilitiate our daily work.

However, for each new project that requires a monorepo, we must choose between the two. It really depends on the situation; if you require more structure and Nx has the necessary plugins, I would recommend going with Nx. If you have an old project that needs to be switched quickly or a project that requires a lot of flexibility that you won't find in the Nx plugins, I recommend going with Turborepo.

For example, we use Turborepo internally because we have a variety of apps, some of which would not work directly with Nx. In most cases, we use Nx for new client projects because it is easier to manage dependencies and imposes a specific architecture.

In conclusion, use whatever best suits your needs.