Security News
tea.xyz Spam Plagues npm and RubyGems Package Registries
Tea.xyz, a crypto project aimed at rewarding open source contributions, is once again facing backlash due to an influx of spam packages flooding public package registries.
@semantic-release/npm
Advanced tools
Package description
The @semantic-release/npm package is designed to automate the process of releasing new versions of npm packages. It updates the package version in package.json and publishes the package to the npm registry based on semantic versioning rules and the commit messages history. This tool is part of the Semantic Release ecosystem, which aims to fully automate the package release workflow, including determining the next version number, generating the release notes, and publishing the package.
Update package version
This configuration snippet for the Semantic Release setup in the package.json file demonstrates how to automatically update the package version in package.json and publish the package to the npm registry. The 'npmPublish' option is set to true to enable publishing.
"release": {
"prepare": [
{
"path": "@semantic-release/npm",
"npmPublish": true
}
]
}
Publish to npm registry
This configuration enables the automatic publishing of the package to the npm registry as part of the release process. It specifies that the @semantic-release/npm plugin should be used for the publishing step.
"release": {
"publish": [
{
"path": "@semantic-release/npm",
"npmPublish": true
}
]
}
Standard Version is a utility for versioning using semver and CHANGELOG generation powered by conventional commits. Unlike @semantic-release/npm, it is more focused on manual versioning control and does not automatically publish to npm, but it automates version bumping and changelog generation.
Release It! is a CLI tool to automate versioning and package publishing, similar to @semantic-release/npm. It supports various plugins for different release steps, including changelog generation, version bumping, and publishing. Release It! offers more configurability for manual intervention in the release process compared to the fully automated approach of @semantic-release/npm.
Readme
semantic-release plugin to publish a npm package.
Step | Description |
---|---|
verifyConditions | Verify the presence of the NPM_TOKEN environment variable, or an .npmrc file, and verify the authentication method is valid. |
prepare | Update the package.json version and create the npm package tarball. |
addChannel | Add a release to a dist-tag. |
publish | Publish the npm package to the registry. |
$ npm install @semantic-release/npm -D
The plugin can be configured in the semantic-release configuration file:
{
"plugins": ["@semantic-release/commit-analyzer", "@semantic-release/release-notes-generator", "@semantic-release/npm"]
}
The npm token authentication configuration is required and can be set via environment variables.
Automation tokens are recommended since they can be used for an automated workflow, even when your account is configured to use the auth-and-writes
level of 2FA.
If you are publishing to the official registry and your pipeline is on a provider that is supported by npm for provenance, npm can be configured to publish with provenance.
Since semantic-release wraps the npm publish command, configuring provenance is not exposed directly.
Instead, provenance can be configured through the other configuration options exposed by npm.
Provenance applies specifically to publishing, so our recommendation is to configure under publishConfig
within the package.json
.
For package provenance to be signed on the GitHub Actions CI the following permission is required to be enabled on the job:
permissions:
id-token: write # to enable use of OIDC for npm provenance
It's worth noting that if you are using semantic-release to its fullest with a GitHub release, GitHub comments, and other features, then more permissions are required to be enabled on this job:
permissions:
contents: write # to be able to publish a GitHub release
issues: write # to be able to comment on released issues
pull-requests: write # to be able to comment on released pull requests
id-token: write # to enable use of OIDC for npm provenance
Refer to the GitHub Actions recipe for npm package provenance for the full CI job's YAML code example.
Variable | Description |
---|---|
NPM_TOKEN | Npm token created via npm token create |
Options | Description | Default |
---|---|---|
npmPublish | Whether to publish the npm package to the registry. If false the package.json version will still be updated. | false if the package.json private property is true , true otherwise. |
pkgRoot | Directory path to publish. | . |
tarballDir | Directory path in which to write the package tarball. If false the tarball is not be kept on the file system. | false |
Note: The pkgRoot
directory must contain a package.json
. The version will be updated only in the package.json
and npm-shrinkwrap.json
within the pkgRoot
directory.
Note: If you use a shareable configuration that defines one of these options you can set it to false
in your semantic-release configuration in order to use the default value.
The plugin uses the npm
CLI which will read the configuration from .npmrc
. See npm config
for the option list.
The registry
can be configured via the npm environment variable NPM_CONFIG_REGISTRY
and will take precedence over the configuration in .npmrc
.
The registry
and dist-tag
can be configured under publishConfig
in the package.json
:
{
"publishConfig": {
"registry": "https://registry.npmjs.org/",
"tag": "latest"
}
}
Notes:
.npmrc
file will override any specified environment variables.registry
or dist-tag
under publishConfig
in the package.json
will take precedence over the configuration in .npmrc
and NPM_CONFIG_REGISTRY
The npmPublish
and tarballDir
option can be used to skip the publishing to the npm
registry and instead, release the package tarball with another plugin. For example with the @semantic-release/github plugin:
{
"plugins": [
"@semantic-release/commit-analyzer",
"@semantic-release/release-notes-generator",
[
"@semantic-release/npm",
{
"npmPublish": false,
"tarballDir": "dist"
}
],
[
"@semantic-release/github",
{
"assets": "dist/*.tgz"
}
]
]
}
When publishing from a sub-directory with the pkgRoot
option, the package.json
and npm-shrinkwrap.json
updated with the new version can be moved to another directory with a postversion
. For example with the @semantic-release/git plugin:
{
"plugins": [
"@semantic-release/commit-analyzer",
"@semantic-release/release-notes-generator",
[
"@semantic-release/npm",
{
"pkgRoot": "dist"
}
],
[
"@semantic-release/git",
{
"assets": ["package.json", "npm-shrinkwrap.json"]
}
]
]
}
{
"scripts": {
"postversion": "cp -r package.json .. && cp -r npm-shrinkwrap.json .."
}
}
FAQs
semantic-release plugin to publish a npm package
The npm package @semantic-release/npm receives a total of 1,145,383 weekly downloads. As such, @semantic-release/npm popularity was classified as popular.
We found that @semantic-release/npm demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 4 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
Tea.xyz, a crypto project aimed at rewarding open source contributions, is once again facing backlash due to an influx of spam packages flooding public package registries.
Security News
As cyber threats become more autonomous, AI-powered defenses are crucial for businesses to stay ahead of attackers who can exploit software vulnerabilities at scale.
Security News
UnitedHealth Group disclosed that the ransomware attack on Change Healthcare compromised protected health information for millions in the U.S., with estimated costs to the company expected to reach $1 billion.