@firefoxic/release-it

A powerful release script that automates the entire release process including updating changelog, npm publishing and GitHub releases.

Purpose

Publishing a new version of a package is a routine sequence of several steps involving running commands, editing files, entering passwords, copying text to GitHub, and so on. It's easy to make a mistake at any stage, especially when editing CHANGELOG.md. Do it all with a single command or push to the release branch.

Usage

• In GitHub CI

  1. Create a release action. See the release.yaml file for an example, where important points are described in the comments.
  2. In the settings of your package on https://npmjs.com, enable trusted publishing (if you haven't already).
  3. Push the branch named starting with release (see below) to GitHub.

• Locally

  1. On the branch with a name starting with release (see below), just run:

     npx @firefoxic/release-it
     # or
     # pnpm dlx @firefoxic/release-it

  2. And enter OTP.

Requirements

• Node.js

• Git repository with GitHub remote

• GitHub CLI (gh) for locally using

  # First time setup — authenticate with GitHub
  gh auth login

Branch-based Release Types

The release script uses branch names to determine the release type:

• release → Stable release (e.g., 1.0.0)
• release-alpha → Alpha prerelease (e.g., 1.0.0-alpha.1)
• release-beta → Beta prerelease (e.g., 1.0.0-beta.1)
• release-rc → Release candidate (e.g., 1.0.0-rc.1)
• release- → Numbered prerelease (e.g., 1.0.0-1)

Version Detection

The script automatically determines the version bump based on changelog content:

• ### Changed → Major version (breaking changes)
• ### Added → Minor version (new features)
• ### Fixed → Patch version (bug fixes)

Authentication

• CI/CD: Uses NPM trusted publishing
• Local: Interactive OTP prompt or --otp flag
• GitHub: Requires gh auth login or GITHUB_TOKEN environment variable

Changelog restrictions

• The name of the changelog file is CHANGELOG.md.

• The format of the changelog is consistent with Keep a changelog.

• Descriptions of all user-important changes are already in the changelog under the heading [Unreleased]. Ideally, you should commit them along with the changes themselves.

• If this is the first release of a package, there should be only one reference for [Unreleased] at the end of the changelog in the following format for correct reference updating:

  [Unreleased]: https://github.com/<user-name>/<project-name>/compare/v0.0.1...HEAD