@continuous-auth/semantic-release-npm
v4.0.0
Published
semantic-release plugin to publish a npm package
Downloads
1,232
Readme
@continuous-auth/semantic-release-npm
semantic-release plugin to publish a npm package using CFA for 2FA codes.
| 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. |
Install
$ npm install @continuous-auth/semantic-release-npm -D
Usage
The plugin can be configured in the semantic-release configuration file:
{
"plugins": ["@semantic-release/commit-analyzer", "@semantic-release/release-notes-generator", "@continuous-auth/semantic-release-npm"]
}
Configuration
npm registry authentication
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.
npm provenance
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
.
npm provenance on GitHub Actions
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.
Environment variables
| Variable | Description |
| ----------- | ----------------------------------------------------------------------------------------------------------------------------- |
| NPM_TOKEN
| Npm token created via npm token create |
| CFA_PROJECT_ID
| Project ID on CFA |
| CFA_SECRET
| Secret configured on CFA for this repository |
Options
| 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.
npm configuration
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:
- The presence of an
.npmrc
file will override any specified environment variables. - The presence of
registry
ordist-tag
underpublishConfig
in thepackage.json
will take precedence over the configuration in.npmrc
andNPM_CONFIG_REGISTRY
Examples
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",
[
"@continuous-auth/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",
[
"@continuous-auth/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 .."
}
}