semantic-release-npmx
v1.1.0
Published
semantic-release plugin to publish a npm package that supports monorepos
Downloads
39
Maintainers
Readme
[IN DEVELOPMENT] semantic-release plugin to publish a npm package based off of the work done here. Supports monorepos (lerna, and yarn) but is restricted to fixed versioning for now.
| Step | Description | |
|--------------------|-----------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------|
| verifyConditions
| Verify the presence of the NPM_TOKEN
environment variable, create or update the .npmrc
file with the token and verify the token 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 semantic-release-npmx -D
Usage
The plugin can be configured in the semantic-release configuration file:
{
"plugins": [
"@semantic-release/commit-analyzer",
"@semantic-release/release-notes-generator",
"semantic-release-npmx",
]
}
Configuration
Npm registry authentication
The npm authentication configuration is required and can be set via environment variables.
Both the token and the legacy (username
, password
and email
) authentication are supported. It is recommended to use the token authentication. The legacy authentication is supported as the alternative npm registries Artifactory and npm-registry-couchapp only supports that form of authentication.
Note: Only the auth-only
level of npm two-factor authentication is supported, semantic-release will not work with the default auth-and-writes
level.
Environment variables
| Variable | Description |
| -------------- | ----------------------------------------------------------------------------------------------------------------------------- |
| NPM_TOKEN
| Npm token created via npm token create |
| NPM_USERNAME
| Npm username created via npm adduser or on npmjs.com |
| NPM_PASSWORD
| Password of the npm user. |
| NPM_EMAIL
| Email address associated with the npm user |
Use either NPM_TOKEN
for token authentication or NPM_USERNAME
, NPM_PASSWORD
and NPM_EMAIL
for legacy authentication
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 the package tarball. If false
the tarball is not be kept on the file system. This is relative to the cwd of where semantic-release is called from, even for sub-packages | false
|
| access
| The default publish access for the package. This only applies to scoped packages | restricted
|
Note: The pkgRoot
directory must contains 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 in the package.json
and will take precedence over the configuration in .npmrc
and NPM_CONFIG_REGISTRY
:
{
"publishConfig": {
"registry": "https://registry.npmjs.org/",
"tag": "latest"
}
}
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",
["semantic-release-npmx", {
"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 postpublish
npm script. For example with the @semantic-release/git plugin:
{
"plugins": [
"@semantic-release/commit-analyzer",
"@semantic-release/release-notes-generator",
["semantic-release-npmx", {
"pkgRoot": "dist",
}],
["@semantic-release/git", {
"assets": ["package.json", "npm-shrinkwrap.json"]
}]
]
}
{
"scripts": {
"postpublish": "cp -r dist/package.json . && cp -r dist/npm-shrinkwrap.json ."
}
}
Monorepos
Configuration is pretty much the same, but nested to include configuration for subpackages as well.
tarballDir
will be relative to the root directory.
{
"plugins": [
["semantic-release-npmx", {
"default": {
"npmPublish": false,
"tarballDir": "dist",
},
"package1": {
"npmPublish": true,
"tarballDir": "dist",
}
}],
]
}
TODO
- [ ] Handle independant versioning. This will probably require modifications to semantic-release itself. The context object is what tracks the nextRelease/Version information and that i calculated internally by SR. Perhaps if that functinality was exported as a default plugin?
- [ ] Add tests for scoped publishing, especially for restricted access repositories