Security News
NIST Misses 2024 Deadline to Clear NVD Backlog
NIST has failed to meet its self-imposed deadline of clearing the NVD's backlog by the end of the fiscal year. Meanwhile, CVE's awaiting analysis have increased by 33% since June.
standard-version
Advanced tools
The standard-version npm package is a utility for versioning and changelog generation based on conventional commits. It automates the process of updating the version number in your package.json file, generating a changelog, and creating a new Git tag.
Version Bumping
This command will bump the version in your package.json file based on the conventional commits in your repository. It will also create a new Git tag for the release.
npx standard-version
Changelog Generation
This command will generate a changelog based on the conventional commits and bump the version as a minor release. The changelog will be updated with the new changes.
npx standard-version --release-as minor
Pre-release Versioning
This command will bump the version to a pre-release version (e.g., 1.0.0-beta.0) and update the changelog accordingly.
npx standard-version --prerelease beta
Custom Release Types
This command allows you to specify a custom version number for the release, overriding the automatic version bump based on conventional commits.
npx standard-version --release-as 1.1.0
semantic-release automates the whole package release workflow including: determining the next version number, generating the release notes, and publishing the package. It is more comprehensive than standard-version and integrates with CI/CD pipelines for fully automated releases.
release-it is a versatile release tool for versioning, changelog generation, and publishing. It is highly configurable and can be extended with plugins. Compared to standard-version, release-it offers more flexibility and customization options.
lerna is a tool for managing JavaScript projects with multiple packages. It can also handle versioning and changelog generation for monorepos. While it offers similar functionalities to standard-version, lerna is specifically designed for managing multi-package repositories.
stop using
npm version
, usestandard-version
it rocks!
Automatic versioning and CHANGELOG management, using GitHub's new squash button and
the recommended workflow for conventional-changelog
.
how it works:
master
branch, select the Squash and Merge option.git checkout master; git pull origin master
standard-version
git push --follow-tags origin master; npm publish
standard-version
does the following:
npm run
scriptInstall and add to devDependencies
:
npm i --save-dev standard-version
Add an npm run
script to your package.json:
{
"scripts": {
"release": "standard-version"
}
}
Now you can use npm run release
in place of npm version
.
This has the benefit of making your repo/package more portable, so that other developers can cut releases without having to globally install standard-version
on their machine.
Install globally (add to your PATH
):
npm i -g standard-version
Now you can use standard-version
in place of npm version
.
This has the benefit of allowing you to use standard-version
on any repo/package without adding a dev dependency to each one.
To generate your changelog for your first release, simply do:
# npm run script
npm run release -- --first-release
# or global bin
standard-version --first-release
This will tag a release without bumping the version in package.json.
When ready, push the git tag and npm publish
your first release. \o/
If you typically use npm version
to cut a new release, do this instead:
# npm run script
npm run release
# or global bin
standard-version
As long as your git commit messages are conventional and accurate, you no longer need to specify the semver type - and you get CHANGELOG generation for free! \o/
After you cut a release, you can push the new git tag and npm publish
(or npm publish --tag next
) when you're ready.
Use the flag --prerelease
to generate pre-releases:
Suppose the last version of your code is 1.0.0
, and your code to be committed has patched changes. Run:
# npm run script
npm run release -- --prerelease
you will get version 1.0.1-0
.
If you want to name the pre-release, you specify the name via --prerelease <name>
.
For example, suppose your pre-release should contain the alpha
prefix:
# npm run script
npm run release -- --prerelease alpha
this will tag the version 1.0.1-alpha.0
npm version
To forgo the automated version bump use --release-as
with the argument major
, minor
or patch
:
Suppose the last version of your code is 1.0.0
, you've only landed fix:
commits, but
you would like your next release to be a minor
. Simply do:
# npm run script
npm run release -- --release-as minor
you will get version 1.1.0
rather than the auto generated version 1.0.1
.
NOTE: you can combine
--release-as
and--prerelease
to generate a release. This is useful when publishing experimental feature(s).
If you use git hooks, like pre-commit, to test your code before committing, you can prevent hooks from being verified during the commit step by passing the --no-verify
option:
# npm run script
npm run release -- --no-verify
# or global bin
standard-version --no-verify
If you have your GPG key set up, add the --sign
or -s
flag to your standard-version
command.
If you want to commit generated artifacts in the release commit (e.g. #96), you can use the --commit-all
or -a
flag. You will need to stage the artifacts you want to commit, so your release
command could look like this:
"prerelease": "webpack -p --bail",
"release": "git add <file(s) to commit> && standard-version -a"
# npm run script
npm run release -- --help
# or global bin
standard-version --help
Use the silent
option to stop standard-version
from printing anything
to the console.
var standardVersion = require('standard-version')
// Options are the same as command line, except camelCase
standardVersion({
noVerify: true,
infile: 'docs/CHANGELOG.md',
silent: true
}, function (err) {
if (err) {
console.error(`standard-version failed with message: ${err.message}`)
}
// standard-version is done
})
patches:
git commit -a -m "fix(parsing): fixed a bug in our parser"
features:
git commit -a -m "feat(parser): we now have a parser \o/"
breaking changes:
git commit -a -m "feat(new-parser): introduces a new parsing library
BREAKING CHANGE: new library does not support foo-construct"
other changes:
You decide, e.g., docs, chore, etc.
git commit -a -m "docs: fixed up the docs a bit"
but wait, there's more!
Github usernames (@bcoe
) and issue references (#133) will be swapped out for the
appropriate URLs in your CHANGELOG.
Tell your users that you adhere to the standard-version
commit guidelines:
[![Standard Version](https://img.shields.io/badge/release-standard%20version-brightgreen.svg)](https://github.com/conventional-changelog/standard-version)
standard-version
different from semantic-release
?semantic-release
is a fully automated library/system for versioning, changelog generation, git tagging, and publishing to the npm registry.
standard-version
is different because it handles the versioning, changelog generation, and git tagging for you without automatic pushing (to GitHub) or publishing (to an npm registry). Use of standard-version
only affects your local git repo - it doesn't affect remote resources at all. After you run standard-version
, you still have to ability to review things and correct mistakes if you want to.
They are both based on the same foundation of structured commit messages (using Angular format), but standard-version
is a good choice for folks who are not yet comfortable letting publishes go out automatically. In this way, you can view standard-version
as an incremental step to adopting semantic-release
.
We think they are both fantastic tools, and we encourage folks to use semantic-release
instead of standard-version
if it makes sense for them.
The instructions to squash commits when merging pull requests assumes that one PR equals, at most, one feature or fix.
If you have multiple features or fixes landing in a single PR and each commit uses a structured message, then you can do a standard merge when accepting the PR. This will preserve the commit history from your branch after the merge.
Although this will allow each commit to be included as separate entries in your CHANGELOG, the entries will not be able to reference the PR that pulled the changes in because the preserved commit messages do not include the PR number.
For this reason, we recommend keeping the scope of each PR to one general feature or fix. In practice, this allows you to use unstructured commit messages when committing each little change and then squash them into a single commit with a structured message (referencing the PR number) once they have been reviewed and accepted.
ISC
FAQs
replacement for `npm version` with automatic CHANGELOG generation
The npm package standard-version receives a total of 466,494 weekly downloads. As such, standard-version popularity was classified as popular.
We found that standard-version demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 6 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
NIST has failed to meet its self-imposed deadline of clearing the NVD's backlog by the end of the fiscal year. Meanwhile, CVE's awaiting analysis have increased by 33% since June.
Security News
Cloudflare has launched a setup wizard allowing users to easily create and manage a security.txt file for vulnerability disclosure on their websites.
Security News
The Socket Research team breaks down a malicious npm package targeting the legitimate DOMPurify library. It uses obfuscated code to hide that it is exfiltrating browser and crypto wallet data.