np
np copied to clipboard
Github Action
I'd like to automate bumping version on every push to main
or PR merge. Could not find any np
related GH Action on that matter
np is a better publish not just a npm version updater. Do you want a github action which will just update the version in the package.json
file?
I think an action like this could be created if the next version could be determined by the recent commit messages. But for that, it would need to understand the commit convention (patch for fixes, minor for features, major when breaking).
I donβt think it makes much sense for this to exist. Let's see the feature list
- Interactive UI
- β Impossible on GHA
- Ensures you are publishing from your release branch (main and master by default)
- π€·ββοΈ Native on GHA
- Ensures the working directory is clean and that there are no unpulled changes
- π€·ββοΈ Native on GHA
- Reinstalls dependencies to ensure your project works with the latest dependency tree
- π€·ββοΈ Native on GHA
- Ensures your Node.js and npm versions are supported by the project and its dependencies
- π€·ββοΈ Native on GHA
- Runs the tests
- π€·ββοΈ Native on GHA
- Bumps the version in package.json and npm-shrinkwrap.json (if present) and creates a git tag
- π€·ββοΈ Native with npm
- Prevents accidental publishing of pre-release versions under the latest dist-tag
- π I guess this
- Publishes the new version to npm, optionally under a dist-tag
- π€·ββοΈ Native with npm
- Rolls back the project to its previous state in case publishing fails
- π€·ββοΈ Native on GHA
- Pushes commits and tags (newly & previously created) to GitHub/GitLab
- π€·ββοΈ Possible with regular
git push
- π€·ββοΈ Possible with regular
- Supports two-factor authentication
- β Impossible on GHA
- Enables two-factor authentication on new repositories
- π€·ββοΈ It doesn't make sense for a pre-existing repo on GHA
- Opens a prefilled GitHub Releases draft after publish
- π This, but there are plenty of solutions for that
- Warns about the possibility of extraneous files being published
- π This, but what is it going to do? Block the release? GHA is not interactive
- See exactly what will be executed with preview mode, without pushing or publishing anything remotely
- π€·ββοΈ Native by calling
npm pack
on every CI run
- π€·ββοΈ Native by calling
- Supports GitHub Packages
- π€·ββοΈ Native with npm
If anybody's interested into automating the versioning, it can be done using lerna
and conventional commits. See my TS monorepo for a working setup example. There are important points which affect the setup, and yours might be different:
- that's a monorepo of npm packages-programs (not packages-components or anything to do with front-end/React/Angular etc),
- it's all on TypeScript (I keep non TS libraries as separate repos to simplify the monorepo),
- all packages are pure-ESM, including CLI's; I'm not producing any CJS builds, only ESM and in many cases IIFE for browsers (
esbuid
can't do CJS or UMD). - it's a stateful devops setup, that is, CI produces build artifacts and commits them. That can be avoided and you can see it in projects where there's no
version
field inpackage.json
, take Facebook projects for example β nothing inpackage.json
is mentioning any version-specific information.
Quick overview of such setup:
- you'd always commit by calling
git-cz -n
, I set upcm
npm script to trigger the CLI β each commit gets formatted properly so that laterlerna --conventional-commits
can recognise them and calculate correct versions β see here - enable conventional commits in lerna config β see here
- it's a long story but I'm not using
lerna publish
; I only bump versions usinglerna version
. Practically, that'sturbo
scriptturbo run letspublish
which callsletspublish
script in each package which looks like thisyarn publish || :
. The assumption is, unbumped packages will refuse to publish, but since process exits with non-zero code, we append|| :
. The reason behind not usinglerna publish
is I want to granularly control what and when gets pushed to remote. - I had a botched release months ago similar to this; the CI was authenticated, build artifacts were committed on remote, with git tags and all β and β npm refused to
npm publish
. In the end, I switched toyarn publish
and it magically worked again. That's why I'm still sticking withyarn
(alsoturbo
allegedly has better integration onyarn
projects, don't know if it's still true). - The version calculation still fails in some cases, for example, if you migrate from GitHub to let's say SourceHut, version calculation will count the "from" state since the start of the git repository existence, so any package which has ever had a "breaking" type commit will be
major
semver-bumped. In my case, tens of packages accidentally got major-bumped. Theoretically, if time and resources were unlimited, we'd draw up a "staging" npm instance and test each release there first, reviewing all versions.