npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

bump-and-release

v2.7.1

Published

A tiny command line helper to bump and release packages

Downloads

13

Readme

Bump and Release

npm David David GitHub Workflow Status

Bump and Release is a tiny command line helper to bump and release packages.

Installation

> cd your-project
> npm install --save-dev bump-and-release

Configuration

Update your package.json file with the following scripts calls:

"scripts": {
  "bump": "bump-and-release -t bump",
  "release": "bump-and-release-t release"
}

If you are using a configuration file, you can pass it via the parameter -c:

"scripts": {
  "bump": "bump-and-release -t bump -c ./config/app-config.js",
  "release": "bump-and-release-t release -c ./config/app-config.js"
}

Or if you name it .bump-and-release.config.js and put it in the same location as your package.json file, it will be taken into account automatically.

This:

  "bump": "bump-and-release -t bump -c .bump-and-release.config.js"

is equivalent to:

  "bump": "bump-and-release -t bump"

if the file .bump-and-release.config.js can be found next to your package.json.

Bump

By default, the "bump" command will:

  1. Run the following preflight validations
    • check if the current branch name is master
    • check if the current branch has a tracking remote
    • check if that remote is either github/master or origin/master
    • check if your repo has uncommitted files
  2. Prompt the user to choose from a list of possible "new versions"
    • patch
    • minor
    • major
  3. Update your package.json file with the new version
  4. Update your package-lock.json file with the new version
  5. Stage and commit those files
  6. Push to the tracking remote

If any of those tasks fail, the process stops.

Bump example

Release

By default, the "release" command will:

  1. Run the following preflight validations
    • check if the current branch name is master
    • check if the current branch has a tracking remote
    • check if that remote is github/masteror origin/master
    • check if your repo has uncommitted files
  2. Stage and commit any modified files
  3. Tag the version with the following template: vCurrentVersion
  4. Push code and tags to the tracking remote

If any of those tasks fail, the process stops.

Release example

Custom configuration

While the defaults are pretty straight forward, it is possible to override them with a configuration file.

Example

module.exports = {
  /**
   * { array of strings }
   * List of all the branches this tool is NOT allowed to work with.
   * This entry takes precedence over the next one (allowedBranches).
   * This is ignored if bump.local or release.local is true.
   */
  disallowedBranches: [],
  /**
   * { array of strings }
   * List of all the branches this tool is allowed to work with.
   * This is ignored if bump.local or release.local is true.
   */
  allowedBranches: ["master", "main"],
  /**
   * { array of strings }
   * List of all the remotes this tool is allowed to work with.
   * This is ignored if bump.local or release.local is true.
   */
  allowedRemotes: ["github/master", "upstream/main"],

  /**
   * Configurations specific to the "bump" command.
   */
  bump: {
    /**
     * { boolean }
     * Flag indicating that this is a monorepo handled by Lerna with
     * non-independent version (all packages have the same version).
     * Bump will read lerna.json to find the current version, and the
     * location of all the packages listed in the prop "packages".
     * Bump will try to update ALL the packages.json under each and
     * every package listed in that prop.
     */
    lerna: true,
    /**
     * { boolean }
     * Flag indicating that all changes will remain
     * local, preventing anything to be pushed to the remote(s).
     */
    local: true,
    /**
     * { function }
     * Function that takes the new version as a parameter
     * and that returns the string that will be used during
     * the commit phase of the bump.
     */
    commitMessage: (version) =>
      `chore: bumping version for next release: ${version}`,
    /**
     * { array of objects }
     * List of possible "next" versions to be offered to
     * the user at the prompt. These values are the same
     * that are accepted from method `inc()` of the
     * node-semver library.
     * https://github.com/npm/node-semver
     * There is also an extra one called "custom", allowing
     * the user to enter a version manually.
     *
     * NOTE: there is a "special" case which is not a version.
     * It's used to add a separator when all the values are
     * displayed at the prompt.
     * The value for the type is "separator".
     */
    nextPossible: [
      {
        /**
         * { number }
         * The position of this prompt within other prompts.
         * The indexing starts at 0.
         */
        pos: 0,
        /**
         * { string }
         * The type of release as defined in node-semver.
         * Possible values are major, premajor, minor,
         * preminor, patch, prepatch or prerelease.
         * It also accepts "separator".
         */
        type: "prepatch",
        /**
         * { string }
         * Identifier to be used to prefix premajor,
         * preminor, prerelease or prepatch version increments.
         * For example: "alpha", "beta", "rc", etc.
         */
        identifier: "beta",
        /**
         * { boolean }
         * Flag to enable or disable a specific release.
         */
        enabled: true,
        /**
         * { boolean }
         * Flag to make that particular version the default
         * selection.
         */
        default: true,
        /**
         * { function }
         * Function that returns the prompted line for a
         * specific version.
         */
        prompt: (type, version) =>
          `[${type}] ... bump to next ${type} (${version})`,
        /**
         * { number }
         * The desired position for this specific release in
         * the prompt.
         */
      },
      {
        type: "patch",
        prompt: (type, version) =>
          `[${type}] ... bump to next ${type} (${version})`,
      },
      {
        type: "minor",
        prompt: (type, version) =>
          `[${type}] ... bump to next ${type} (${version})`,
      },
      {
        type: "major",
        prompt: (type, version) =>
          `[${type}] ... bump to next ${type} (${version})`,
      },
      {
        type: "separator",
      },
      {
        type: "custom",
        prompt: (type) => `[${type}] ... enter a custom version`,
      },
    ],
    /**
     * { array of objects }
     * List of tasks to run before the bump is actually
     * executed. It is useful to run some tests, or
     * linting one last time for example. Each object has 3
     * keys: the name of the task, the action to run and
     * and optional verbose boolean to indicate if the
     * output of the task should be visible or not (it is
     * not verbose by default).
     *
     * NOTES: any files modified during these steps will
     * automatically be staged, committed and pushed to the
     * remote.
     */
    prebump: [
      {
        name: "run tests",
        command: "npm run test",
        verbose: true,
      },
      {
        name: "lint the files",
        command: "npm run lint",
      },
    ],
  },

  /**
   * Configurations specific to the "release" command.
   */
  release: {
    /**
     * { boolean }
     * Flag indicating that all changes will remain
     * local, preventing anything to be pushed.
     */
    local: true,
    /**
     * { function }
     * Function that takes the current version as a parameter
     * and that returns the string that will be used during
     * the commit phase of the release.
     */
    commitMessage: (version) => `chore: tagging release ${version}`,
    /**
     * { object }
     * Object specifying if this release should be tagged
     * (using the "enabled" boolean flag) and what prefix
     * to use when actually tagging (using the "prefix" string
     * flag).
     */
    tag: {
      enabled: true,
      prefix: "v",
    },
    /**
     * { array of objects }
     * List of tasks to run before the release is actually
     * tagged. It is useful to run some tests, or
     * generate a changelog for example. Each object has 3
     * keys: the name of the task, the action to run and
     * and optional verbose boolean to indicate if the
     * output of the task should be visible or not (it is
     * not verbose by default).
     *
     * NOTES: any files modified during these steps will
     * automatically be staged, committed and pushed to the
     * remote.
     */
    prerelease: [
      {
        name: "run tests",
        command: "npm run test",
        verbose: true,
      },
      {
        name: "generate changelog",
        command: "npm run changelog",
      },
    ],
  },
};

Next Available Versions

The possible "next" versions to be offered to the user at the prompt are the same that are accepted from method inc() of the node-semver library.

Here are possible values, assuming the current version of a package is 1.0.0.

| type | current version | new version | | -------- | --------------- | ------------ | | prepatch | 1.0.0 | 1.0.1-beta.0 | | patch | 1.0.0 | 1.0.1 | | preminor | 1.0.0 | 1.1.0-beta.0 | | minor | 1.0.0 | 1.1.0 | | premajor | 1.0.0 | 2.0.0-beta.0 | | major | 1.0.0 | 2.0.0 |

NOTE: the "beta" identifier can be customized by providing the key "identifier".

License

MIT © Arno Versini