npm version {major,minor,patch} && npm publish as an action. Full npm lifecycle support and gh-release auth support. Opinionated and has a few assumptions.

Generate a publish token on npm then set it as an action secret (NPM_TOKEN in this example).

name: Version and Release

on:
  workflow_dispatch:
    inputs:
      newversion:
        description: 'Semantic Version Bump Type (major minor patch)'
        required: true

env:
  node_version: lts/*
  
concurrency: # prevent concurrent releases
  group: npm-bump
  cancel-in-progress: true

jobs:
  version_and_release:
    runs-on: ubuntu-latest
    outputs:
      tagName: ${{ steps.npm-bump.outputs.release_tag }}
    steps:
    - uses: actions/checkout@v3
      with:
        # fetch full history so things like auto-changelog work properly
        fetch-depth: 0
    - name: Use Node.js ${{ env.node_version }}
      uses: actions/setup-node@v3
      with:
        node-version: ${{ env.node_version }}
        # setting a registry enables the NODE_AUTH_TOKEN env variable where we can set an npm token.  REQUIRED
        registry-url: 'https://registry.npmjs.org'
    - run: npm i
    - run: npm test
    - name: Version and publish to npm
      id: npm-bump
      uses: bcomnes/npm-bump@v2
      with:
        git_email: bcomnes@gmail.com
        git_username: ${{ github.actor }}
        newversion: ${{ github.event.inputs.newversion }}
        push_version_commit: true # if your prePublishOnly step pushes git commits, you can omit this input or set it to false.
        github_token: ${{ secrets.GITHUB_TOKEN }} # built in actions token.  Passed tp gh-release if in use.
        npm_token: ${{ secrets.NPM_TOKEN }} # user set secret token generated at npm
    - run: echo ${{ steps.npm-bump.outputs.release_tag }}

This will give you a push-button triggered action that runs npm version {major,minor,patch}, git push --follow-tags and finally npm publish.

It is advisable to set a prePublishOnly lifecycle hook that runs, at a minimum, git commit pushing, so that local runs of npm version && npm publish will push the version commits to git the same way as this action will.

{
  "scripts": {
    "prepublishOnly": "git push --follow-tags"
  }
}

With that lifecycle set, you can omit the push_version_commit input, or set it to false.

The following dependencies and npm lifecycle scripts are recommended for a fully automated release process that includes:

• changelog generation
• github release creation with changelog contents
• automated action based package publishing
• parity with a local release process (you can still run npm version && npm publish and get all of the above benefits)
• See swyx's article for a more in depth description.

{
  "devDependencies": {
    "auto-changelog": "^1.16.2",
    "gh-release": "^3.5.0"
  },
  "scripts": {
    "prepublishOnly": "git push --follow-tags && gh-release -y",
    "version": "auto-changelog -p --template keepachangelog auto-changelog --breaking-pattern 'BREAKING CHANGE:' && git add CHANGELOG.md"
  }
}

Additionally, you should run your tests in order to block a release that isn't passing. Automate only when green.

• git_email (REQUIRED): The email address used to create the version commit with.
• git_username (REQUIRED): The name to use for the version commit. e.g. github.actor
• newversion (REQUIRED): The version bump type to perform (e.g. major, minor, path). See npm version docs for more info. Pass this as an interactive variable.
• push_version_commit (Default: false): Run git push --follow-tags after running npm version. Enable this if you don't configure a prepublishOnly hook that pushes git commits.
• publish_cmd (Default: npm publish): The command to run after npm version. Useful if you are just using npm to version a package, but not publish to npm (like an action).
• github_token: Pass the secrets.GITHUB_TOKEN to enable gh-release capabilities.
• npm_token: An npm token scoped for publishing. Required in most cases. Used to create the release.

• release_tag: The name of the created git tag as described by git describe --tags

Something about your workflow is creating or modifying files before versioning.

Things to check for:

• Is your package-lock.json (or equivalent) getting modified in preparation to versioning? Considder adding these to your .gitignore as lock files provide a less realistic environment to work around in modules.
• Adding a simple git status step prior to the npm bump step might reveal which files are blocking the publish.
• For files that get modified during the version step, you can stage them along side your release in the version lifecycle event.

You must set the registry-url input on the actions/setup-node action to 'https://registry.npmjs.org' at a minimum. Github actions does some wacky stuff to .npmrc like setting up a NODE_AUTH_TOKEN input for the npm token. npm-bump takes advantage of this behavior so its an assumed requirement. See this article for more info on this bizarre behavior. Also if you script modifications to a local .npmrc, this can mess up the actions/setup-node configuration.

Yes, just pass secrets.GITHUB_TOKEN as the npm_token input, and set your registry endpoint to https://npm.pkg.github.com in the actions/setup-node action.

Yes, but you have to create a new Github machine account, create a Personal Access Token, store it as an action secret, and then use that as the npm_token. Kind of a PITA.

No, not right now. I couldn't think of why this would be a good reason. Open an issue if you have ideas.

Nope, you can completely override the npm publish command with whatever you want (e.g. npm run release which can run whatever you want related to a release.) This enables you to publish to things like the Github marketplace, create github releases etc.

Yes. npm-bump now offers a major version ref you can install with.

Testing node stuff is usually straight forward (npm test). Sometimes though, its not. Leaving the test responsibilities to the consumer makes the action file more clear.

Some projects don't need dependencies to release. Sometimes install steps require external system dependencies. It was decided to keep the install step inside the action consumer scope in order to increase clarity around what is happening.

MIT