When was the last time when you were thinking about “What’s going on with monorepos now”? Is Lerna still the best choice or just Yarn Workspaces could be enough?
I did it a couple days ago and I have something to share with you.
So let’s get started.
First of all, what does the Monorepo mean?
Wikipedia says
In version control systems, a monorepo (“mono” meaning ‘single’ and “repo” being short for ‘repository’) is a software development strategy where code for many projects is stored in the same repository
When you may need monorepos in your dev life?
Imagine the situation:
- You have several libraries, projects, etc.
- All of them are stored in a separated git repos.
- Some of these packages should be as dependencies in your other packages.
- And you are still continue to develop your packages (some of them may not work correctly in integration with other, etc.)
So the ordinary dev’s reality :)
What could you do in such a case?
- The worst scenario 👎
You can publish your “medium rare” packages. Include them in the package.json of your main project as dependencies. Then, when you fix something, you republish them, up the version in package.json, yarn install again… Repeat as many times as you will find bugs.
If you ever thought about this workflow, keep reading, please 👉
- Good scenario 👋
You can use yarn link. In that case, you can test your packages working in integration, without publishing packages every time after you fixed bugs.
What is the main issue here? If you have a lot of packages you can simply miss something. You also need to remember to do yarn unlink after you are done with fixes and published your stuff. Also, you need to pay attention to what version do you use right now, published or linked one.. Yes, your editor may show you which package is linked right now in node_modules , but still, it could be risky to miss something. It’s hard to manage everything when you have many packages and cross dependencies
- The Best scenario (for my opinion) 👍
You can use the monorepos. All your packages will be stored in one git repository, with their own package.json’s, linked with each other, etc. It’s easy to develop, easy to manage. When your development is done, all your stuff could be published at once or package-by-package. No need yarn link/unlink, etc
So in short. We may want to use monorepos when:
- We want a bit simplest code base management
- We have a huge codebase with cross dependiences in packages
- We have several applications and the packages used inside every application
- We don’t want to deal with
yarn link, etc if we need to fix something inside our package - We want flexible versioning, publishing, and changelog generation
- Just We can :)
Let’s see in short what projects we can use for monorepos in 2022
yarn/npm Workspaces.
yarn workspaces npm workspaces
It’s Low-level primitive used by other tools. Actually, if you just need to link and install dependencies, it will be enough.
- Link dependencies +
- Run commands across the packages +
- Automated packages publishing (we can run publish command one-by-one in each package, or write jour own automation) —
- Automated version managing —
Lerna (⭐️ 31.4k)
- Link dependencies +
- Run commands across the packages +
- Automated packages publishing +
- Automated version managing +
- Caching —
Turborepo (⭐️ 5.3k)
- Link dependencies +
- Run commands across the packages +
- Automated packages publishing (can be done via complimentary tools) —
- Automated version managing (can be done via complimentary tools) —
- Caching +++
NX (⭐️ 10.3k)
- More than just monorepo tool +
- Automated packages publishing —
- Automated version managing —
- Caching +++
- Not as easy as wanted —
BIT (⭐️ 14.6k)
- More than just monorepo tool +
- Good for micro frontends +
Before we go further I want you to give a try to NX.
- The project has a great codegen tool and provides consistent dev experience for any framework
- When you want to add a package to monorepo NX will ask you what should it be. For example, React application, React library, or React component. Based on choices NX will generate a proper config for each package inside your monorepo
- It works extremely fast
I have a feeling that NX is something great! Maybe I just didn’t find use cases for such a multitool in my project and stopped to dive deeper. Also, it was a little hard to make my project work with NX.
But it’s only my experience ;)
So, for me (and my project), the best tool is TURBOREPO
Here is the list of benefits which are important for me (you may find the whole list in official documentation)
Incremental builds
Building once is painful enough, Turborepo will remember what you’ve built and skip the stuff that’s already been computed.
Content-aware hashing
Turborepo looks at the contents of your files, not timestamps to figure out what needs to be built.
Remote Caching
Share a remote build cache with your teammates and CI/CD for even faster builds.
Parallel execution
Execute builds using every core at maximum parallelism without wasting idle CPUs.
Task pipelines
Define the relationships between your tasks and then let Turborepo optimize what to build and when.
Profile in your browser
Generate build profiles and import them in Chrome or Edge to understand which tasks are taking the longest.
Finally, lets see the digits.
Previously I used Lerna as a monorepo engine. So I will compare Lerna speed vs Turborepo
My monorepo contains one React application and 13 packages. One of the packages is the UI Library Kit which contains 102 React components
build-packages — build all packages except the main application
build-app — build all packages and the main application
Okay. It was a small description of what’s going on with monorepos in 2022 from my point of view. Hope the information was helpful for someone.
Let me know what you guys think in the comments :)
Top comments (0)