Releasing related npm packages means deciding which versions change, writing Git tags, and publishing the right packages. Lerna gives maintainers a workflow for those steps. This review asks whether that release work justifies adopting it alongside an existing package workspace.
Choose the release model first
The release guide describes fixed and independent versioning. Fixed mode uses a single version line, but it does not mean every package receives every release. The guide explains that unchanged packages can retain older versions and documents an option to force synchronized versions. Independent mode lets maintainers choose version bumps separately for changed packages.
For separately consumed components, independent versions may fit the release policy. A coordinated package family may suit fixed mode. These are workflow recommendations, not findings from the sandbox. Choose the model that matches your compatibility commitments before running commands that write versions and tags.
What happened when we ran it
The supplied sandbox run installed Lerna commit b00fa03 in 76 seconds, built it in 37 seconds, and completed the test step successfully in 90 seconds on October 15, 2026. It recorded 1,795 dependencies. The installed development checkout occupied 726 MB. No passing-test count was supplied.
The recorded configuration specified 3 CPUs, 8 GB RAM, and image label lab-node:22. The label does not establish the actual Node or operating-system version. These timings describe the upstream checkout in that sandbox; they do not measure an application's task graph, caching benefits, or registry publication.
Npm audit reported 84 known vulnerabilities: 18 critical, 33 high, 33 moderate, and 0 low. The summary does not identify affected packages, production exposure, or reachable exploit paths. Inspect the advisory details before dependency approval. The count alone does not establish exposure from installing the published CLI.
Before installation, the checkout contained 1,507 files, about 64,083 lines of source, and occupied 7.7 MB. The scan recorded 7 CI workflow files, monorepo workspaces, no Dockerfile, and no tests directory. The successful test step is a separate observation from the directory scan.
The 726 MB figure measures the installed development checkout. It does not isolate dependency size or measure the incremental cost of adopting Lerna in your repository.
Keep the package manager responsible for dependencies
The getting-started guide makes the boundary explicit: Lerna is not responsible for installing and linking dependencies. When package-manager workspaces are configured, Lerna defaults to their existing package patterns.
The guide documents npx lerna init --dryRun to preview initialization changes. That is a useful next step in a disposable branch: inspect the proposed changes and package selection before applying them. This command is a documentation example; the supplied sandbox result does not record executing it.
Check which packages should be published. The release guide demonstrates using "private": true to keep an application out of npm publication.
Versioning has Git side effects
The documented version workflow updates package versions, commits the change, creates a tag, and pushes the commit and tag. It does not publish packages to npm. The documented publish workflow adds registry publication.
Lerna always uses npm to publish packages. The guide says teams using another package manager still need appropriate publishing configuration in .npmrc. Plan registry authentication and Git permissions separately from repository build checks; the successful test step does not establish release readiness.
The from-package mode compares local package versions with those published to npm and publishes packages whose local versions are greater. It does not require those versions to have been calculated with Lerna. Teams with existing version scripts can therefore evaluate publication separately from version calculation.
Compare the missing workflow
Changesets lets contributors declare how their changes should be released. It handles package versions, changelogs, and publication from those declarations. Consider it when reviewable release intent is the missing part of your process. The supplied README identifies itself as the development branch for Changesets v3 and points v2 users to a maintenance branch; this review does not verify a released Changesets version.
Turborepo documents task scheduling and caching using existing package scripts and a turbo.json file. Consider it when repeated repository tasks are the immediate problem and releases already work. For this review's release-focused reader, evaluate Lerna against the package-release work it would replace. The sandbox provides no speed or footprint comparison between these tools.
Start with the initialization preview, choose fixed or independent versioning, and rehearse publication with disposable packages before using production credentials. If dependency linking is the only problem, start with the workspace configuration.