Lerna leaves dependency installation to the package manager
At commit 0be4313, Lerna gives a JavaScript or TypeScript monorepo one CLI for running package scripts, finding changed projects, assigning versions, creating Git tags, and publishing to npm. It supports fixed versioning, where packages share a release line, and independent versioning, where each changed package can receive its own bump. Filters such as --scope, --since, and --include-dependencies make the commands useful in local development and CI.
That scope has a firm edge. The getting-started guide says Lerna does not install or link dependencies; npm, Yarn, pnpm, or Bun workspaces do that work. The measured checkout reflects the split: it is an npm workspace monorepo with 1,528 files and about 64,578 lines of source. Adopting Lerna means keeping the package manager as the dependency authority, then using Lerna above it for tasks and releases.
Version 10 requires Node 22.13 or newer
The lerna package at commit 0be4313 identifies itself as version 10.0.1 and accepts Node ^22.13.0, ^24.0.0, or ^26.0.0. That excludes Node 18 and 20 even if the application packages still run there. Check developer laptops, release runners, and reusable CI images before upgrading. The repository pins a still newer Node for its own development through Volta, which is separate from the published package's engine range.
Installation itself did not require a service or secret in our fresh container. It did require 1,847 packages and left 685 MB on disk, which is a substantial toolchain addition for a repository that only wants version prompts. Teams using ephemeral CI runners should budget the download and cache the package-manager store. A release-only setup may be better served by Changesets if Lerna's task runner will sit unused.
What happened when we ran it
We cloned commit 0be4313 and ran its install, build, and test targets in our 3-CPU, 8 GB sandbox. Installation took 48 seconds, the build completed in 34 seconds, and Vitest passed all 28 tests in 112 seconds with 0 failures. Those results show that the supplied npm workflow was reproducible in the stated unprivileged Node 22 container. They do not measure an application's task graph or the speedup from caching.
Npm audit found 42 known vulnerabilities in the installed tree: 20 high, 20 moderate, 2 low, and 0 critical. The lab block does not identify which packages are affected or whether they ship with the CLI, so the result should not be stretched into a runtime exploit claim. It is still a poor number for teams with strict dependency policy. The checkout occupied 7.7 MB before installation and 685 MB after the package set arrived.
Our scan found 5 CI workflow files, no Dockerfile, and no top-level tests directory. The absence of that directory did not mean there were no tests, since the command found and passed 28 Vitest cases. A supplied container is also unnecessary for normal use, but organizations that standardize builds in images will have to make their own Node 22 base and caching choices.
Nx 23.1.2 powers Lerna's task order and cache
At commit 0be4313, lerna run reads package scripts, respects project dependencies, and can restrict work to packages changed since a Git reference. Modern Lerna delegates that scheduling to Nx. Local caching is available after adding or configuring nx.json, provided the task is deterministic and its outputs are described correctly. The docs specifically warn that a test which calls a backend API is unsuitable for caching because the same inputs can produce different results.
The successful 34-second repository build is evidence that the checked-out task graph worked once, not evidence that Nx will accelerate every monorepo. Cache value depends on repeated inputs and correct output declarations. Distributed task execution goes further and needs Nx Cloud plus CI jobs started by the operator. Nx coordinates those jobs, while the organization still supplies runners with the same source and environment.
Lerna 10 writes versions, Git tags, and npm records
In Lerna 10.0.1, lerna version can update package versions, commit the changes, create tags, and push them. lerna publish adds registry publication, while from-package compares local package versions with npm and publishes newer ones. These commands can save a maintainer from writing release glue, but they also act on Git and the registry. A trial should use lerna init --dryRun, a disposable repository, and a non-production registry before anyone grants publishing credentials.
The docs make another boundary explicit: publishing always goes through npm, even when the workspace uses another package manager. That means .npmrc, registry authentication, access levels, two-factor rules, and Git permissions must all agree. The 112-second test run did not exercise anyone's production registry credentials. An open request for npm security-key support, issue 3273, has a proposed browser-auth implementation in pull request 4417, so affected maintainers should verify its release status before switching.
Recent maintenance is active, with 286 issues and pull requests open
GitHub reported 36,054 stars, an MIT license, and 286 open issues and pull requests when fetched. The last push was September 8, 2026, and release 10.0.1 arrived on August 19, 2026. Recent work included a fix for a missing peer dependency and a change that skips unnecessary package managers during release. The current push date and active pull request discussion matter more than the age of Lerna's original design.
Maturity does not make every old release edge disappear. The 42 audit findings deserve a dependency review, and the security-key publishing request shows that npm authentication changes can expose gaps in established tooling. Still, the clean build and 28 passing tests make Lerna a sensible choice for teams that need both task coordination and package publishing. If only one half is needed, Nx, Turborepo, or Changesets asks for a clearer and usually narrower commitment.