In this article join me as I migrate my Pedalboard monorepo from Lerna to NX.

So I've recently seen that the Lerna project announced (in it’s main README) that it will no longer be maintained –

Just like that with no second warning, a project that was the groundbreaking pioneer in monorepo’s management called it quits,
Indeed a shame but no surprise there, right? I mean, seriously, this project had “not for long, mates” written all over it, and yet I still decide that it will power a small portion of my Pedalboard monorepo.

Why?

Have a look in my “No BS monorepo – Part 1” article where I explain why, at the time, Lerna appealed more to me. As a matter of a fact, if it wasn’t going “deprecated” I probably would still use it, since I kept it very focused on the tasks it does best.
Oh well, this is how our industry rolls sometimes… ¯\_(ツ)_/¯

First of all let’s check what I used Lerna for in my monorepo.

• Be able to launch npm/yarn scripts from the root project which will run on all the packages on my monorepo
• Be able to bump a package version, along with generating a CHANGELOG.md file and git tagging it
• Be able to publish the changed packages to NPM

Great. So I know what I require from the alternative, but what alternatives are out there?
This wonderful monorepo.tools resource compares the leading solutions for monorepos today, check it out if you haven't already.

Scrolling down to the bottom you can see a very detailed comparison and it looks like NX is the clear winner with most “checks”. Adding that to the fact that I hear more and more how NX improved monorepo workflows in the industry, and I think it is time to have a go with it –

NX it is.

So let’s start with our first goal:

Launch npm/yarn scripts from the root project which will run on all the packages on my monorepo

Going to NX docs I found a resource talking about how to add NX to an already Lerna powered monorepo.
As suggested I run this command on the project’s root:

npx add-nx-to-monorepo

I’m prompted with a question of whether I would like to use Nx Cloud or not. Nx Cloud is a feature which allows a project to persist its script running computations (such as tests results, etc.) in the cloud, thus making following calls to those scripts run much faster, given that nothing was altered to bust the cache.
This is something I don’t feel I need at the moment, but if I regret it I can add it later on.

I read that there is a cool feature of seeing the monorepo dependencies graph, and being a FED at heart I cannot resist. Let’s check it out by running yarn nx graph

Oh nice 🙂 I feel like a proud parent looking at a picture of my kids. Here is my little components package and look there – it depends on the hooks package. How adorable
ok, ok, we’re moving on.

On the root project’s package.json I have the scripts which run on the entire packages, such as testing or linting. Here is how it looks now using lerna:

"scripts": {    "test": "lerna run test --",    "coverage": "yarn test --coverage",    "lint": "lerna run lint",    "build": "lerna run build",    "publish:lerna": "lerna publish --yes --no-verify-access",    "coverage:combined": "pedalboard-scripts aggregatePackagesCoverage && nyc report --reporter lcov"  }, 

If I run yarn test for example, it runs the test script for each package and I get this output:

Now let’s try and make it with NX.
The NX command is a bit different. I need to use the “run-many” command and state the target script I want to run.

So the test command will now look something like this:

"test": "nx run-many --target=test --all", 

This works well, let's change the lint and build commands as well:

"scripts": {        "test": "nx run-many --target=test --all",        "coverage": "yarn test --coverage",        "lint": "nx run-many --target=lint --all",        "build": "nx run-many --target=build --all",        "publish:lerna": "lerna publish --yes --no-verify-access",        "coverage:combined": "pedalboard-scripts aggregatePackagesCoverage && nyc report --reporter lcov"    }, 

Notice that the “coverage” command is using the “yarn test” command in turn, and this seems to work as expected, passing the “–coverage” param and producing the coverage directory in all relevant packages. One thing I’ve noticed though is that it does not output the coverage results in the terminal as Lerna did.

The coverage:combined does not involve Lerna and still works as before. You can read more about it here

Ok, this completes our first goal of having the ability to run scripts for all packages. Cool and pretty straightforward.

In the next episode we will dive into how to detect changes and bump package versions accordingly, along with generating a CHANGELOG.md file and git tagging it. Stay tuned.

As always, if you know of other means of achieving what's written above, please make sure to share them with the rest of us 🙂

Hey! If you liked what you've just read check out @mattibarzeev on Twitter 🍻

Art by Cornelis Cort, Achenbach Foundation for Graphic Arts