Automating Versioning and Releases in JavaScript Projects
These six tools handle version bumps, changelog generation, and publishing for JavaScript packages, but they differ in automation levels and target workflows. semantic-release and auto focus on fully automated CI pipelines, removing human interaction from the release process. np and release-it offer interactive or configurable CLI workflows for manual triggers. lerna specializes in managing releases across monorepos with multiple packages. standard-version provides a lightweight way to bump versions and generate changelogs based on commit conventions without enforcing a full publish pipeline.
Npm Package Weekly Downloads Trend
Github Stars Ranking
Stat Detail
Automating Versioning and Releases in JavaScript Projects
Managing releases involves more than just running npm publish. You need to bump versions, generate changelogs, tag git commits, and notify users. The tools auto, lerna, np, release-it, semantic-release, and standard-version all solve this problem, but they approach it from different angles. Let's compare how they handle automation, configuration, and real-world workflows.
🤖 Automation Model: CI-Only vs Interactive vs Hybrid
The biggest difference lies in who triggers the release. Some tools run only in Continuous Integration (CI), while others run on your local machine.
semantic-release is fully automated. It runs in CI, analyzes commits, and publishes without human input.
// semantic-release: .releaserc.json
{
"branches": ["main"],
"plugins": ["@semantic-release/commit-analyzer"]
}
auto is also CI-focused but uses PR labels to decide version bumps.
# auto: .autorc.yml
plugins:
- npm
- released
np is strictly interactive. You run it locally, and it prompts you for confirmation.
# np: CLI command
npx np
release-it supports both modes. You can run it locally or in CI with flags.
// release-it: .release-it.json
{
"git": { "commit": true, "tag": true },
"npm": { "publish": true }
}
lerna is often run in CI for monorepos but can be triggered locally.
// lerna: lerna.json
{
"version": "independent",
"command": { "publish": { "conventionalCommits": true } }
}
standard-version is a local tool. You run it to bump versions, then you commit manually.
// standard-version: package.json script
{
"scripts": {
"release": "standard-version"
}
}
🛠️ Configuration Style: Files vs CLI Flags
How you define rules varies from dedicated config files to package.json entries.
semantic-release uses a dedicated config file or package.json key.
// semantic-release: package.json
{
"release": {
"branches": ["+([0-9])?(.{+([0-9]),x}).x"]
}
}
auto relies on .autorc files in JSON, YAML, or JS formats.
// auto: .autorc.js
module.exports = {
"owner": "my-org",
"repo": "my-repo"
};
np reads settings from package.json but relies mostly on prompts.
// np: package.json
{
"np": {
"yarn": true,
"contents": "."
}
}
release-it uses .release-it.json or similar config files.
// release-it: .release-it.json
{
"hooks": {
"before:init": ["npm test"]
}
}
lerna requires a lerna.json root file for monorepo settings.
// lerna: lerna.json
{
"packages": ["packages/*"],
"version": "4.0.0"
}
standard-version configures behavior via package.json or CLI flags.
// standard-version: package.json
{
"standard-version": {
"skip": { "tag": true }
}
}
📦 Monorepo Support: Single vs Multiple Packages
Some tools handle multiple packages in one repo, while others expect a single package.
semantic-release handles monorepos but requires specific plugins per package.
// semantic-release: multi-package setup
// Each package needs its own .releaserc or config
auto supports monorepos by detecting multiple package.json files.
# auto: monorepo command
auto shipit --monorepo
np is designed for single packages. It does not support monorepos natively.
# np: single package only
npx np
release-it supports workspaces but requires manual configuration for multiple packages.
// release-it: workspaces config
{
"npm": { "publish": true, "workspace": "packages/*" }
}
lerna is built specifically for monorepos. It manages linking and versioning together.
# lerna: publish all changed packages
lerna publish from-package
standard-version is single-package focused. Monorepos need custom scripts.
# standard-version: run per package
cd packages/a && npx standard-version
📝 Changelog Generation: Automatic vs Conventional
All tools can generate changelogs, but they differ in how they parse commit messages.
semantic-release generates changelogs automatically using conventional commits.
// semantic-release: plugin config
{
"plugins": ["@semantic-release/changelog"]
}
auto generates notes based on PR labels and merge commits.
# auto: generate changelog
auto changelog
np relies on npm or external tools for changelogs during publish.
# np: no built-in changelog gen
# Usually paired with conventional-changelog-cli
release-it uses plugins to generate changelogs from git logs.
// release-it: changelog plugin
{
"plugins": {
"@release-it/conventional-changelog": { "preset": "angular" }
}
}
lerna generates changelogs per package when using conventional commits.
// lerna: enable changelogs
{
"command": { "version": { "conventionalCommits": true } }
}
standard-version is dedicated to generating changelogs based on commits.
# standard-version: run generation
npx standard-version
🚀 CI/CD Integration: GitHub Actions vs Generic
Integration with pipelines determines how easily you can automate releases.
semantic-release has native plugins for GitHub, GitLab, and CircleCI.
# semantic-release: GitHub Actions
- name: Release
run: npx semantic-release
auto integrates deeply with GitHub PR checks and releases.
# auto: GitHub Actions
- uses: intuit/auto@v10
np is not designed for CI. It requires interactive input.
# np: CI usage not recommended
# Requires manual trigger locally
release-it works in CI if you disable interactive prompts.
# release-it: CI script
- run: npx release-it --ci
lerna runs in CI to publish updated packages in a monorepo.
# lerna: CI publish
- run: npx lerna publish from-package --yes
standard-version runs in CI to bump versions, but publishing is manual.
# standard-version: CI version bump
- run: npx standard-version --dry-run
🤝 Similarities: Shared Ground Between Release Tools
Despite their differences, these tools share common goals and standards.
1. 📜 Conventional Commits Support
- Most tools parse commit messages to decide version bumps.
- Enables automatic Major, Minor, or Patch increments.
# Example: Commit message format
feat: add new login feature
fix: resolve timeout issue
2. 🏷️ Git Tagging
- All tools create git tags to mark release points.
- Ensures you can revert or reference specific versions.
# Example: Git tag created
v1.2.3
3. 📦 npm Publishing
- All tools (except
standard-versionalone) can publish to npm. - Handles authentication and registry updates.
# Example: Publish command
npm publish
4. 🔒 Safety Checks
- Most tools check for uncommitted changes or failed tests.
- Prevents accidental releases of broken code.
# Example: Pre-check
npm test && git status
5. 🔌 Plugin Ecosystems
semantic-release,auto, andrelease-itsupport plugins.- Allows integration with Slack, Sentry, or custom APIs.
// Example: Plugin usage
plugins: ['@semantic-release/slack']
📊 Summary: Key Differences
| Feature | auto | lerna | np | release-it | semantic-release | standard-version |
|---|---|---|---|---|---|---|
| Primary Use | PR Label Automation | Monorepo Management | Interactive CLI | Configurable CLI | Full CI Automation | Local Version Bump |
| Automation | High (CI) | High (CI/Local) | Low (Local) | Medium (Hybrid) | High (CI) | Low (Local) |
| Monorepo | Yes | Native Support | No | Configurable | Plugin Based | Manual |
| Changelog | Auto (PR Based) | Auto (Commit Based) | Manual/External | Auto (Plugin) | Auto (Commit Based) | Auto (Commit Based) |
| Config File | .autorc | lerna.json | package.json | .release-it.json | .releaserc | package.json |
💡 Final Recommendation
semantic-release is the top choice for teams wanting zero-touch releases in CI. It enforces discipline and removes human error from versioning.
auto is best for GitHub-heavy teams that want release notes driven by pull request labels rather than commit messages.
lerna remains the king of monorepos. If you have multiple packages in one repo, this is the standard tool.
np is perfect for solo developers or small teams who want a safe, interactive local release process.
release-it offers the most flexibility for custom workflows that need both local and CI support.
standard-version is ideal for projects that just want changelogs and version bumps without automated publishing.
Final Thought: Pick the tool that matches your team's workflow. If you want full automation, go with semantic-release or auto. If you need monorepo support, choose lerna. If you prefer manual control, np or release-it will serve you well.
How to Choose: auto vs lerna vs np vs release-it vs semantic-release vs standard-version
- auto:
Choose
autoif your team uses GitHub or GitLab extensively and wants to determine version bumps via pull request labels. It is ideal for organizations that want release notes generated automatically based on PR metadata without manual version input. - lerna:
Choose
lernaif you are managing a monorepo with multiple packages that need coordinated versioning and publishing. It is the standard choice for linking dependencies between packages in a single repository and handling independent or fixed version modes. - np:
Choose
npif you prefer an interactive CLI experience for single-package releases where you manually trigger the process. It is perfect for developers who want to run tests, bump versions, and publish in one local command with safety checks. - release-it:
Choose
release-itif you need a highly configurable release tool that supports both interactive and automated modes. It suits projects that require custom hooks, git tags, and npm publishing steps without committing to a fully opinionated CI-only workflow. - semantic-release:
Choose
semantic-releaseif you want a fully automated release pipeline triggered by commits in your CI environment. It is best for teams that enforce conventional commits and want to eliminate manual versioning steps entirely. - standard-version:
Choose
standard-versionif you need a simple tool to bump versions and generate changelogs locally based on commit messages. It works well for projects that want conventional changelogs without the complexity of a full automated publishing system.
Popular Comparisons
README for auto
auto CLI
auto is a tool designed to seamlessly automate the release workflow.
It is powered by semantic version labels on pull requests.
This approach does not require you to change your code or make any drastic changes to your current workflow.
While intended to run in a continuous integration (CI) environment, all auto commands can run locally as well.
Installation
auto is distributed through npm, but you can use it with a variety of package management platforms.
npm install auto
For auto installation in non-npm environments follow these instructions.
Getting Started
Getting started with auto is super easy.
Prerequisites
If your project is already published or has releases then you need to make sure that your last release is tagged and that it's the Latest Release on GitHub.
To tag your last release find the last commit where you bumped the version and run the following commands with your version number.
git tag v1.2.3
git push --tags
Then on GitHub go to your project's releases and click Draft a new release.
In the Tag version field enter the version number you just tagged and click Publish release.
Setup Steps
-
(OPTIONAL) Initialize all options and configure label text. If this is not run then
autowill use the default configuration. This command will produce an.autorc. You can configure most flags and all labels/changelogTitles.auto initAll options can also be configured via the
.autorcfile. As CLI options you supply them in snake-case(--foo-bar), but as.autorcoptions you supply them in camelCase(fooBar),Exclusive options (extends, labels) can only be set in the
.autorcand do not exist as CLI flags.Any option in the
.autorcwill get overridden by the CLI flags if provided. The following are options that might be more useful to set in the.autorcthan with a flag:baseBranch Configure what your repo considers the base branch. plugins Specify your plugins to load githubApi If you are using enterprise github, `auto` lets you configure the github API URL that it uses. githubGraphqlApi If you are using enterprise github and your company hosts the graphql at some other URL than the `githubApi`, you can use `githubGraphqlApi` to set the base path for `auto`. The `githubGraphqlApi` gets merged with `/graphql` to build the final URL. -
Configure environment variables
You must configure some environment variables for publishing and releasing to work properly.
GH_TOKEN- Used for updating the changelog and publishing the GitHub releaseNPM_TOKEN- Used to publish to npm. (only with NPM plugin)
Local
.env:You can also store these values in a local file at the root of your project named
.env. Make sure to add this file to your.gitignoreso you don't commit any keys! These environment variables will override any variable already set on the process. This enables you to have a per project configuration that isn't effected by your global setup.PROJECT_ROOT/.env:GH_TOKEN=YOUR_TOKEN NPM_TOKEN=PUBLISH_TOKEN -
Create your project's labels on github. If a label already exist, it will be updated.
The types of labels that
autouses are:- Versioning Labels - used to calculate version numbers and make releases.
- Changelog Labels - These labels do not effect the version calculation but they will change the section the PR displays in the changelog. These are customizable too, and you can even add your own sections. Read more here.
To create the labels for your project on GitHub, run the following command with your
GH_TOKEN.GH_TOKEN=YOUR_TOKEN auto create-labels # or with .env file auto create-labels -
Set up script
autois written so that each tool it exposes is useful in isolation. To version, changelog, publish and release your code all at the same time we've included theshipittool. This tool takes the defaultautoworkflow and puts it into one command.It will:
- Publish canary releases when run from a PR or locally on any branch other than the
baseBranch - Generate a changelog and publish a "latest" release to a package manager when run from the
baseBranch
{ "scripts": { "release": "auto shipit" } }For detailed setup instructions,refer here
- Publish canary releases when run from a PR or locally on any branch other than the
Usage (--help)
$ auto --help
auto
Generate releases based on semantic version labels on pull requests, and
other pull request automation tools.
Synopsis
$ auto <command> <options>
Setup Command
init Interactive setup for minimum working configuration.
info Determine the environment and check if auto is set up correctly
create-labels Create your project's labels on github. If labels exist it will update them.
Pull Request Interaction Commands
label Get the labels for a pull request. Doesn't do much, but the return value lets you write you own
scripts based off of the PR labels!
comment Comment on a pull request with a markdown message. Each comment has a context, and each context only
has one comment.
pr-check Check that a pull request has a SemVer label
pr-status Set the status on a PR commit
pr-body Update the body of a PR with a message. Appends to PR and will not overwrite user content. Each
comment has a context, and each context only has one comment.
Release Commands
version Get the semantic version bump for the given changes. Requires all PRs to have labels for the change
type. If a PR does not have a label associated with it, it will default to `patch`.
changelog Prepend release notes to `CHANGELOG.md`, create one if it doesn't exist, and commit the changes.
release Auto-generate a github release
shipit Context aware publishing.
1. call from base branch -> latest version released (LATEST)
2. call from prerelease branch -> prerelease version released (NEXT)
3. call from PR in CI -> canary version released (CANARY)
4. call locally when not on base/prerelease branch -> canary version released (CANARY)
latest Run the full `auto` release pipeline. Force a release to latest and bypass `shipit` safeguards.
canary Make a canary release of the project. Useful on PRs. If ran locally, `canary` will release a canary
version for your current git HEAD. This is ran automatically from "shipit".
1. In PR: 1.2.3-canary.123.0 + add version to PR body
2. Locally: 1.2.3-canary.1810cfd
next Make a release for your "prerelease" release line. This is ran automatically from "shipit".
1. Creates a prerelease on package management platform
2. Creates a "Pre Release" on GitHub releases page.
Calling the `next` command from a prerelease branch will publish a prerelease, otherwise it will
publish to the default prerelease branch.
Global Options
-V, --version Display auto's version
-v, --verbose Show some more logs. Pass -vv for very verbose logs.
--repo string The repo to set the status on. Defaults to looking in the package definition
for the platform
--owner string The owner of the GitHub repo. Defaults to reading from the package definition
for the platform
--github-api string GitHub API to use
--plugins string[] Plugins to load auto with. (defaults to just npm)
-h, --help Display the help output
Merging Quickly
One caveat of auto is that you need to be mindful of merging multiple PRs at once. You must not merge a PR while another is publishing (ex: lerna publish). While this window is small, it exists and you should know about it.
auto works by looking at the git tree to calculate the version bump then makes commits for the CHANGELOG.md and the new version. If you merge a PR while another is publishing:
- they might try to publish the same version number
- one will try to push over the other's changes and fail
The one exception to this rule with when merging a bunch of PRs with skip-release labels.
You still can't merge a PR that triggers a release and then merge a PR with skip-release. This will result in problem 3 from above.
But you can merge a bunch of PRs with skip-release then merge a PR that triggers a release.
Because skip-release is present no commits are made and the release is fine!
Enterprise
If you are using enterprise Github, auto lets you configure the Github API URL that it uses. You can configure this by using the CLI option --github-api, by setting the value in your .autorc, or during auto init.