5 Best Lerna Alternatives
Tools for JavaScript monorepos and multi-package repos to replace Lerna
As of April 2022 LernaJS is no longer maintained.
Created by Henry Zhu, Lerna’s goal was to automate the workflow of creating and publishing multiple packages for the same javascript repository. That is to say, not to build a “monolith” in the traditional sense of the word where multiple applications or services are developed, built, and deployed in the same repository.
Publishing multiple packages from the same repository solves problems of code-sharing, which are a classic pain of working in a multi-repo architecture, which is different and more scalable than a centralized monolith repo.
Over time, however, Lerna became a synonym for the word “monorepo” in Javascript, without people realizing the difference. As a result, you can now find well over 100k projects on GitHub that depend on Lerna. All of them will now have to find a way to replace Lerna with a new solution.
This shortlist brings you the best of the best options for turning any JS repository into a monorepo — whether it’s for developing a few different projects or components inside, or if its for publishing and code-sharing.
The important thing is to remember why you are looking for such a tool in the first place, and what problem you are trying to solve, such as code-sharing, dependencies, collaboration, discoverability, standardization etc. A monorepo might solve some, but create new problems such as builds, learning-curve, versioning, coupling etc that will make scale very hard later on.
Best of luck, and feel free to ask anything in the comments.
1. Bit
Bit is probably the first tool you should try out.
It solves many of the problems in monorepos. For example, learn here about how Bit solved monorepo dependency management in a short overview written by the maker of pnpm.
As a direct replacement for Lerna it’s a useful fit: You can easily create, version, and publish many (really many) “components” (a few files + configs and metadata) as packages from a single repo to npm, yarn or anywhere you like. Bit is therefore a powerful tool for component libraries and such.
But, Bit is in fact a different beast than most monorepo tools.
Bit is really a tool for components-driven development. It brings together the smooth dev experience of a monorepo (instant code-sharing, collaboration, dependencies, etc) and the scale and benefits of distributed development.
With Bit you can effortlessly share code, collaborate, maintain your system, manage dependencies and more across one or a thousand repositories.
With Bit you are no longer bound by any repo architecture; In your workspace, you can dynamically fetch and work on components from any repo. You can use any component (not just UI; any files with configs and metadata) in any project, collaborate, all dependencies are seamlessly managed, updates propagate, development is standardized etc.
The result is a monorepo-like development experience that stays smooth at any scale without the problems of monorepos or of multirepos. For example, every component is independently versioned, changes automatically propagate to dependencies, builds are incremental and only run for components that changed on the component graph, every code is discoverable, and more.
For organizations, the bit.cloud hosting service which is already in use by some of the world’s best enterprises, where components can be hosted and teams can collaborate with each other to use and update each other’s components. Every component the org writes is an asset for all to build on.
Head over to bit.dev and give Bit a try.
2. Yarn and pnpm workspaces
Addition: pnpm workspace is a really great option for those working with pnpm which in my humble opinion is preferable to Yarn. Up to you.
Yarn Workspaces makes monorepos easier mainly around working with dependencies. In Yarn workspaces they are all linked together so your workspaces become dependent on each other and code remains up to date. That’s a better solution than yarn-link since it does not change the whole system but only relevant workspace.
Additonla benefits include having a single node_modules files which means you dno’t clone dependencies across packages. Also, all dependencies are installte together which help to optimize the installation. A single lockfile means code reviews and version conflicts are made simpler. And finally, you can see code changes from one package to another which is great.
Yarn workspaces is a powerful add-on for any other tool you try to build a monorepo experience with. You can even publish directly with workspaces.
As such, Yarn workspaces makes a very powerful combo with pretty much any tool on the list, and especially tools like Bit, Nx, and Lerna, acting as a lower-level layer of your monorepo management abstraction.
However, you can also publish directly with workspaces. When a workspace is packed into an archive, it dynamically replaces any workspace: dependency with a package version, so you can publish the resulting packages to the remote registry without having to run intermediary steps — consumers will be able to use published workspaces as any other package. Cool!
3. NX
NX is a tool developed by a company called Narwhl which optimizes the build experience of a monorepo, designed for modern web techs.
NX can be used via your CLI and set of editor plugins which help utilize incremental builds that don’t rebuild and retest your entire repo and all itscode on every commit you make.
NX’s command execution allows for consistent commands to test, serve, build, and lint each project. It uses a distributed computation cache so if someone has already built or tested similar code, Nx will speed up the command for everyone else instead of rebuilding or retesting the code from scratch.
With NX comes NX cloud, which aims to help you optimize and improve computation utilization in the could to speed builds and make them more efficient. Here’s a short video of the NX cloud premium solution.
4. Rush
Introduced by , Rush is a powerful monorepo infrastructure that tries to optimize builds and help you version and publish many packages from the same repository.
Like Lerna Rush supports bulk versioning and package publishing, so it detects which packages have changed, automatically bumps all the relevant version numbers, and run npm publish in each folder.
Like Yarn workspaces it lets you run a single npm/yarn/pnpm install for all packages and you can install all the repo’s dependencies in a common folder with symlinks and with a single node modules folder. And just like yarn workspaces, this aims to help you prevent cloned dependencies and dependency conflicts, which at scale become a serious pain.
Rush’s unique installation strategy produces a single shrinkwrap/lock file for all your projects that installs fast. Rush detects your dependency graph and builds your projects in the right order, so if two packages don’t directly depend on each other, Rush parallelizes their build as separate processes.
Rush also handles your builds with incremental builds for upstream and downstream dependencies. Rush even handles cyclic dependencies, by separating versions for projects.
Rush also helps to implement and enforce development policies to help standardize development. For example, when a PR is created, you can require developers to provide a major/minor/patch log entry for the affected projects, which will later be aggregated into a changelog file upon publishing.
5. Turborepo
Recently purchesed by Vercel, Turborepo is a solution for monorepos that is essentially another smart and highly optimized monorepo build system. Some of its key features include:
Incremental builds: 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.
Zero runtime overhead: Turborepo won’t interfere with your runtime code or touch your sourcemaps.
Pruned subsets: Speed up PaaS deploys by generating a subset of your monorepo with only what’s needed to build a specific target.
Task pipelines: Define the relationships between your tasks and then let Turborepo optimize what to build and when.
You cna learn more and get started using this neat tutorial:
