semantic-release-npmx

1.1.0 • Public • Published

📦🚀 + npm
semantic-release-npmx

Semantic release plugin for npm publishing that supports monorepos!

Travis Pipeline Status Code Climate maintainability CodeCov test coverage Dependency Status Dev Dependency Status Dependabot Badge Commitizen Prettier Install Size Licence: MIT

[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

Package Sidebar

Install

npm i semantic-release-npmx

Weekly Downloads

3

Version

1.1.0

License

MIT

Unpacked Size

42 kB

Total Files

7

Last publish

Collaborators

  • jdalrymple