DEV Community

Cover image for How we reduced our nodejs monorepo build time by 70%
Dima Grossman for novu

Posted on • Updated on

How we reduced our nodejs monorepo build time by 70%

At Novu, we use a monorepo to manage our 24 libraries and apps. There are many debates over whether you should use a monorepo or a poly-repo. For us, visibility, code sharing, standardization, easier refactoring, and a few other reasons were the critical factors for choosing this approach for our open-source notification infrastructure project.

TLDR;

We migrated from yarn workspaces & lerna to PNPM and nx.dev

Image description

The bigger, the slower

With all the advantages, there are a few drawbacks to using monorepos. We noticed a particular drawback when scaling the number of packages and amount of code in each one: The time it takes to bootstrap the project and then build any packages within. So a typical GitHub action for a service would run anywhere between 11 to 30 minutes. And that's for each time a PR was created or a code was pushed to remote.

More than that, installing a package locally with yarn install could take around 5 minutes to install and build all the dependencies.

This amount of time spent bootstrapping and building reduced the developer experience and wasted collectively so much talented people's time. Being an open-source project with a growing number of contributors, this was unacceptable.

Debugging the slowest tasks

Inspecting a typical 12 minutes GitHub action, it was clear that two specific steps took almost 70-80% of the overall time:

  • yarn install - takes 5-6 minutes
  • yarn build:{package} - could take from 3-6 minutes to build the selected package and its dependencies.

Migrating from yarn workspaces to PNPM

PNPM is a fast, disk space-efficient package manager(as stated on their website), and from some of the benchmarks, there was a massive improvement in install time against yarn workspaces.

Moving from yarn install that took around 6 minutes, the migration to pnpm was effortless: Just adding a pnpm-workspace.yaml to the project's root and running pnpm install, that's all. The symlinks and dependencies for each package we're efficiently installed, in... wait for it... just 1.5 minutes! And that's without any cache at all! After PNPM caches the majority of the dependencies, it takes less than 40 seconds to build and install the dependencies from the cached store.

Reducing ~4 minutes from the bootstrap time for every CI run and locally for first-time contributors is a HUGE win. But wait, we can do even better.

From Lerna to NX.dev

After seeing the Turborepo demo by vercel, I was intrigued by their distributed caching mechanism. With such a mechanism, we can reuse the already built packages by other maintainers and download the dist assets instead of rebuilding them each time.

turborepo vs nx.dev?
After brief research, we decided to go with nx.dev for multiple reasons:

  • Maturity - nx was in the market for a while now, and they have a pretty big community around them.
  • Performance - Seeing some of the benchmarks nx looks like a faster build system overall.

Our community member nishit-g took over the open GitHub issue and quickly after we had a PR open, the results astonished us: 30 seconds the building step! (Instead of the previous 3-6 minutes building a specific set of packages).

After implementing the nx.cloud for distributed caching, the entire 24 packages take less than 5 seconds when fully cached building. But even without being fully cached due to the intelligent parallelism nx performs and builds our target package in less than 30 seconds.

Summary

Reducing our build times from 12+ minutes to around 3 minutes significantly impacts the developer experience of our maintainers. It also reduces the feedback loop from creating a PR to running our test suite to merging the feature.

HUGE Kudos to nishit-g for migrating us from Lerna to NX. Check him out on his Twitter as well!


You can check the final configuration on our GitHub repository.

Oldest comments (16)

Collapse
 
ihaback profile image
ihaback

Thanks for sharing both numbers & github link!
Love seeing real world repos like this ๐Ÿš€๐Ÿš€

Collapse
 
scopsy profile image
Dima Grossman

With great love, always trying my best on finding how to give back to this amazing community โค๏ธ

Collapse
 
olyno profile image
Olyno • Edited

What about yarn berry? I didn't make any benchmark about it, but i'm using it in a lot of project and never got any issue so far. Not sure it's faster than pnpm, but it could be :p

Also, nice article! Thanks you for sharing with us your story!

Collapse
 
scopsy profile image
Dima Grossman

Actually not heard about berry, i'll check it out. Thank you!

Collapse
 
killshot13 profile image
Michael R. • Edited

I used berry for quite some time to manage web apps built in a monorepo style. (not nearly as many as 24 applications but usually two or three between frontend and backend plus a couple APIs) It was a love-hate relationship.

Maybe if I had been able to build a brand new app from scratch it would have been easier to transition, but ultimately I ended up going back to NPM after v7 came out and everyone was talking about how they've almost managed to catch up with yarn.

Not going to lie, it's still a tad slower, likely considerably slower for a sizable monorepo, but the familiarity and improved verbosity is so much better than the headache berry was causing me every other week.

Collapse
 
biswarup35 profile image
Biswarup Bouri

Try Turborepo

Collapse
 
scopsy profile image
Dima Grossman

Actually we tried, decided to go with NX in the end.

Collapse
 
biswarup35 profile image
Biswarup Bouri

Yep, because there's not enough resource available to get started with Turborepo. Anyway build caching feature is amazing I'm love it โค๏ธ

Collapse
 
jancizmar profile image
Jan Cizmar

We are just migrating to Turborepo, it seems more simple to use then NX and it should be faster as well.

Collapse
 
scopsy profile image
Dima Grossman

That's cool! Congrats Turborepo is very neat and simple indeed. After doing some readings decided to go with NX. Some of the reasons and data we had based on this and a few other benchmarks: github.com/vsavkin/large-monorepo

Collapse
 
karthik2265 profile image
Karhik Suryadevara

Iam a little confused, what is monorepo and polyrepo

Collapse
 
scopsy profile image
Dima Grossman

A monorepo contains multiple projects in a single git repository, and polyrepo means that you have one project per github repository. Hope this explains it to you :)

Collapse
 
karthik2265 profile image
Karhik Suryadevara

Now i understand, Thank you

Collapse
 
airtonix profile image
Zenobius Jiricek • Edited

yeah nah.

A monorepo is not merely a repo that holds many projects.

A monorepo is a repo that holds two or more separate projects that can define their relationship through a dependancy graph.

If you can't do this, then it's just a repo.

Collapse
 
abobos profile image
Blessing Makaraba

Cool Stuff

Collapse
 
lirantal profile image
Liran Tal

Thanks for sharing!

I highly recommend to check out bilt for monorepo management: github.com/giltayar/bilt - would love to hear what you think of it.