Lerna-Lite is Lerna's command set split into nine installable packages
Subset of Lerna in a much smaller & more modular project. Help manage and publish multiple packages in a monorepo/workspace structure
At a glance
- What is it?
- Lerna-Lite takes the monorepo tooling most teams actually use from the original Lerna and republishes it as nine small npm packages, one per command, so a project installs only the version and publish steps it needs. The trade is that it is a documented subset rather than a drop-in replacement.
- Who is it for?
- Adopt Lerna-Lite when your monorepo runs on npm, pnpm, yarn or bun and you want only the Lerna commands you actually call, installed as separate packages so a single command update cannot change the behaviour of the rest. Do not adopt it expecting the full original Lerna, since the project describes itself as a subset and its command list stops at nine.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A subset of Lerna, split along package lines
The repository description is the whole pitch: a subset of Lerna in a much smaller and more modular project, helping to manage and publish multiple packages in a monorepo or workspace structure.
Two decisions follow from that sentence. The first is scope: this is not Lerna with features removed over time, it is a project that started from the commands teams actually use and never intended to carry everything the original does. The second is packaging: the CLI is not one dependency with a binary, it is a set of packages, one per command, and you install the ones you need.
The project is TypeScript, MIT licensed, on the `main` branch, and the release cadence is quick. The tags are v5.6.4 from 2026-10-19, v5.6.3 from 2026-10-14 and v5.6.2 from 2026-09-25, and the last push was on 2026-10-19, so the repository is currently being worked on.
The adoption list in the README is worth reading for a different reason. Among the projects named as using Lerna-Lite are Jest, Vuetify, Inquirer, React Navigation, Volar, Blueprint, Wundergraph, JSCAD, Standard Notes, the NativeScript community and textlint. These are repositories with real release processes and real publishing pipelines, which tells you the tool is used where a broken version bump is expensive.
The README also carries a badge stating that the project is maintained with Lerna-Lite itself, which is the kind of self-hosting detail that tends to either mean the tool is solid or that the maintainer has a bias. Often both.
Nine commands, and a note about publish depending on version
The command list is short and each entry links to the documentation for that package, which is the clearest sign of how the project is organised.
`init` creates a new Lerna-Lite workspace structure and adds `lerna.json`. `changed` lists local packages changed since the last release. `diff` gives a git diff of all packages since the last release. `exec` executes shell commands in each workspace package. `list` lists local packages. `publish` publishes workspace packages. `version` bumps workspace package versions. `run` runs an npm script in each workspace package. `watch` watches for changes and executes commands when fired.
The note under the list explains a dependency that would otherwise surprise you: since the `publish` package depends on the `version` package, installing `@lerna-lite/publish` gives you access to both commands.
That is the design in miniature. The version bump and the publish step are two halves of one operation, so they ship together, while `diff`, `list` and `exec` are independent tools that a team may use once a week and need not drag into every install.
Note also what is absent. There is no `bootstrap` command, no `add` command, and no `repair` command in this list. If your workflow depends on one of those, that is the check to run before you migrate.
Installing one command at a time
There is no global install step and no bundled CLI to fetch. You add the package for the command you want to your development dependencies, and each command documents its own install line.
For the changed command the README gives the install line `npm i @lerna-lite/changed -D`, for the diff command `npm i @lerna-lite/diff -D`, and for the version command `npm i @lerna-lite/version -D`.
The pattern holds across the list. `exec`, `list`, `publish`, `run`, `watch` and `init` are installed the same way, with the package name matching the command name. The `-D` flag puts them in devDependencies, which is correct for a monorepo, since these tools run in CI and on your machine rather than in your published packages.
Because the install is per command, your `package.json` becomes a readable statement of what the release process actually does. A repository that publishes with a version bump and a publish step shows two entries. A repository that also diffs on every release shows three. There is no separate list of enabled features to keep in step.
The trade is a longer dependency list in a large workspace, and the fact that upgrading one command means upgrading one package while the others sit at their own versions.
The scripts show how the project drives its own workspace
The repository's own `package.json` is the best worked example available, since the project builds and tests itself with the commands it publishes. The scripts section reads:
"scripts": {
"local-lerna": "node ./packages/cli/dist/cli.js",
"clean": "remove --glob=\"packages/*/dist\" --glob=\"packages/*/tsconfig.tsbuildinfo\" --stat",
"clean:tarball": "remove --glob packages/**/*.tgz --stat",
"clean:temp": "node scripts/cleanup-temp-files.mjs",
"build": "pnpm clean && tsc --build ./tsconfig.packages.json",
"build:clean": "pnpm clean && tsc --build ./tsconfig.packages.json && echo TSC Build Completed",
"build:full": "pnpm clean && pnpm lint && pnpm format && tsc --build ./tsconfig.packages.json && echo TSC Build Completed",
"build:pnpm": "pnpm -r --stream build",
"init-cmd": "lerna init --independent --exact --use-workspaces",
"changed-cmd": "lerna changed --all",Several things are visible there. The `local-lerna` script runs the built CLI straight out of `packages/cli/dist/cli.js`, which is how you exercise a change to the CLI without publishing it. The `init-cmd` script shows the flags the init command accepts in practice, `--independent --exact --use-workspaces`. The `changed-cmd` script uses `--all`.
The build scripts also show the toolchain: TypeScript project builds through `tsc --build ./tsconfig.packages.json`, pnpm as the package manager, and a `build:pnpm` variant that streams a recursive build across the workspace packages.
That the project dogfoods its own commands is the practical reassurance here. When the `changed` script in this repository calls `lerna changed --all`, it is the same code path a user gets from `@lerna-lite/changed`.
Catalog and workspace protocols, plus token-free publishing
Two capabilities are called out in the README with a note, and both matter for a modern workspace.
The first is protocol support. The README states that Lerna-Lite supports the `catalog:` and `workspace:` protocols for pnpm, yarn and bun, and that Lerna-Lite itself uses both pnpm catalogs and pnpm workspaces internally. In practice this means a dependency written as `workspace:*` or `catalog:` resolves correctly during a version bump or a publish, instead of being written out as a concrete range that the workspace protocol was supposed to keep symbolic.
The repository topics list bun, npm, pnpm, pnpm-workspaces, yarn, yarn-workspaces and workspaces, which matches that claim and tells you the project is tested against more than one package manager rather than being pnpm-only with a compatibility note.
The second is OIDC trusted publishing. The README says it is supported from v4.9.0 and higher, and that GitHub, GitLab and CircleCI workflows can use npm's Trusted Publishing OpenID Connect integration for token-free publishing from CI/CD. The stated benefits are the elimination of long-lived tokens and the automatic generation of Provenance attestations, and the README links a basic test repository for the setup.
This is the part that changes a team's supply chain rather than its ergonomics. A publish job that authenticates with a short-lived OIDC identity has no npm token to leak, and the attestation says who built the package without anyone maintaining a signing key.
What the repository contains, and where the boundaries are
The top level of the repository is a TypeScript monorepo with `packages/` holding one directory per command, plus `scripts/`, `e2e/`, `e2e-utils/`, `helpers/`, `vitest/`, `__fixtures__/` and `docs/`. There is a `pnpm-workspace.yaml`, a `lerna.json`, `tsconfig.base.json`, `tsconfig.packages.json`, an `.npmrc` and a `pnpm-lock.yaml`, along with `AGENTS.md`, `CLAUDE.md`, `TESTING.md`, `CHANGELOG.md`, `CONTRIBUTING.md`, `CODE_OF_CONDUCT.md` and `LICENSE`.
One directory stands out. There is a `.verdaccio/` folder, which is a local npm registry, and it exists so the end to end tests can publish and install packages against a registry that runs inside the test run. That is a mature choice: the alternative is testing the publish path against a real registry, which nobody wants a CI job to do.
The limitation follows from the design. This is a subset, and the subset is bounded by the nine commands. The README's own table of contents links a migration guide for existing Lerna users, a JSON Schema for `lerna.json`, and a wiki page documenting that configuration file, along with a troubleshooting wiki and a release demo wiki.
That a migration guide exists tells you the intended audience is teams already running Lerna who want to move to something smaller. It also means the differences between the two are documented rather than discovered, and the guide is where you should check whether a feature you use today has an equivalent here. The README is explicit that it is a lighter version of the original, and the command list is the honest boundary of that claim.
Where a smaller Lerna wins and where it does not
The case for Lerna-Lite is a release pipeline with a lot of surface area and a small number of operations. A monorepo with dozens of packages that versions independently, publishes to npm and occasionally diffs needs three or four commands, not the full Lerna feature set. Installing three packages instead of one reduces the dependency tree, shortens the install, and means a release of the tool affects only the command that actually changed.
There is also the option to update one command at a time, which the per-package layout makes natural, and the fact that each command has its own documentation directory, so the page you read is about the command you are using.
The case against is that a subset is only a superset if you stay inside it. The original Lerna has grown commands and options over years, and a team that relies on something outside this list will find no equivalent and no migration path in this project. The other real cost is coordination: with nine packages instead of one, your dependency graph has nine entries that can drift out of step, and the README's own advice about keeping multiple product packages on the same version is a symptom of that.
The alternative approach is to keep using the original Lerna and accept its size, or to drop back to the package manager alone and script the version and publish steps yourself with pnpm's own recursive commands, which is what `build:pnpm` in this repository's scripts hints at. That last option removes a dependency entirely and leaves you maintaining the release logic in your own scripts, which is fine for two or three packages and painful for twenty.
For a team that has decided on independent versioning in a pnpm or yarn workspace, the interesting middle option is Lerna-Lite, and the interesting question is only whether your release process fits inside the nine commands.
Editorial conclusion
Adopt Lerna-Lite when your monorepo runs on npm, pnpm, yarn or bun and you want only the Lerna commands you actually call, installed as separate packages so a single command update cannot change the behaviour of the rest. Do not adopt it expecting the full original Lerna, since the project describes itself as a subset and its command list stops at nine. Verify first that the commands you depend on are among init, changed, diff, exec, list, publish, version, run and watch, that the workspace protocol your lockfile uses is supported, and that the version you pin matches the one you tested, with v5.6.4 released on 2026-10-19 and the last push on the same day.
Frequently asked questions
What is Lerna-Lite and how does it differ from Lerna?
Lerna-Lite is described as a subset of Lerna in a much smaller and more modular project, used to manage and publish multiple packages in a monorepo or workspace structure. The difference is packaging and scope: it publishes one npm package per command, and its command list is limited to init, changed, diff, exec, list, publish, version, run and watch.
How do I install Lerna-Lite?
You install the package for each command you need as a dev dependency, for example `npm i @lerna-lite/changed -D`, `npm i @lerna-lite/diff -D` and `npm i @lerna-lite/version -D`. There is no bundled CLI install step, and installing `@lerna-lite/publish` also gives you the version command because the publish package depends on it.
Does Lerna-Lite support pnpm catalogs and workspace protocols?
Yes. The README states that Lerna-Lite supports the `catalog:` and `workspace:` protocols for pnpm, yarn and bun, and that the project itself uses pnpm catalogs and pnpm workspaces internally.
Can Lerna-Lite publish to npm from CI without a long-lived token?
Yes, from v4.9.0 and higher. The README says GitHub, GitLab and CircleCI workflows can use npm Trusted Publishing with OpenID Connect for token-free publishing, which eliminates long-lived tokens and automatically generates Provenance attestations.
Which projects use Lerna-Lite?
The README lists some of the largest projects using it, among them Jest, Vuetify, Inquirer, React Navigation, Volar, Blueprint, Wundergraph, JSCAD, Standard Notes, NativeScript and textlint.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/lerna-lite-lerna-lite)Was this useful?