Détail du package

@release-it-plugins/workspaces

release-it-plugins31.3kMIT5.0.3

release-it plugin for bumping and publishing workspaces

release, release-it, release-it-plugin, plugin

readme

@release-it-plugins/workspaces

This package is a release-it plugin (using release-it's plugin API) that releases each of your projects configured workspaces.

How it works

In order to publish each of your projects workspaces, we first check the root package.json to determine the locations of each of your workspaces (handling both globbing and various formats for workspaces). Once we have identified all of the workspaces, we bump the package.jsons version field to the selected version and publish the package (by changing into the package's root folder and calling npm publish).

Usage

Installation using your projects normal package manager, for example:

npm install --save-dev @release-it-plugins/workspaces

# or

yarn add --dev --ignore-workspace-root-check @release-it-plugins/workspaces

Once installed, configure release-it to use the plugin.

For example, configuring via package.json would look like this:

{
  "release-it": {
    "plugins": {
      "@release-it-plugins/workspaces": true
    }
  }
}

Often times the root package.json for a workspace setup is commonly not published, in order to configure release-it to avoid attempting to publish the top level package (in addition to publishing your workspace packages), you would add the following to your release-it config (again showing package.json style configuration):

{
  "release-it": {
    "plugins": {
      "@release-it-plugins/workspaces": true
    },
    "npm": false
  }
}

Configuration

For the most part @release-it-plugins/workspaces "does the right thing", but there are a few things that are configurable.

A quick summary (in TypeScript syntax) of the supported options (more details on each just below):

interface ReleaseItWorkSpacesConfiguration {
  /**
    Disables checks for `npm` registry and login info.

    Defaults to `false`.
  */
  skipChecks?: boolean;

  /**
    Should the packges be published (`npm publish`)?

    Defaults to `true`.
  */
  publish?: boolean;

  /**
    Path to a custom script used to publish each workspace. The script is
    executed with a number of environment variables set so that it can perform
    the publish however desired.

    The following environment variables will be provided:

    - `RELEASE_IT_WORKSPACES_PATH_TO_WORKSPACE`: relative path to the workspace
    - `RELEASE_IT_WORKSPACES_TAG`: the npm dist-tag being published
    - `RELEASE_IT_WORKSPACES_ACCESS`: access level (public/private)
    - `RELEASE_IT_WORKSPACES_OTP`: one-time password for 2FA
    - `RELEASE_IT_WORKSPACES_DRY_RUN`: boolean indicating a dry run

    When omitted, an appropriate `npm` or `pnpm` command is executed
    automatically.
  */
  publishCommand?: string;

  /**
    Specifies which `dist-tag` to use when publishing.

    Defaults to `latest` for non-prerelease and the prelease type for
    prereleases (e.g. `1.0.0-beta.1` would be `beta`, and `1.0.0-alpha.1` would
    be alpha).
  */
  distTag?: string;

  /**
    The array of workspaces in the project.

    Defaults to the `package.json`'s `workspaces` value.
  */
  workspaces?: string[];

  additionalManifests?: {
    /**
      An array of `package.json` files that should have their `version`
      property updated to the newly released version.

      Defaults to `['package.json']`.
    */
    versionUpdates?: string[];

    /**
      An array of `package.json` files that should have their `dependencies`,
      `devDependencies`, `optionalDependencies`, and `peerDependencies` values
      updated to the newly published version.
    */
    dependencyUpdates?: string[];
  };
}

skipChecks

By default, @release-it-plugins/workspaces confirms that the npm registry is up and running (via npm ping) and that you are authenticated properly (via npm whoami). If you'd prefer to avoid these checks (e.g. your custom npm registry does not support them) you can specify the skipChecks option:

{
  "release-it": {
    "plugins": {
      "@release-it-plugins/workspaces": {
        "skipChecks": true
      }
    }
  }
}

publish

@release-it-plugins/workspaces publishes to the npm registry. However, some repository configurations prefer to commit + tag then let CI publish the actual packages to the registry. This is where the publish option comes in:

{
  "release-it": {
    "plugins": {
      "@release-it-plugins/workspaces": {
        "publish": false
      }
    }
  }
}

With this configuration, the package.json files in your workspaces would be updated with the new version information but the packages would not be published.

publishCommand

Provide a path to a custom script that is executed for each workspace instead of running npm publish or pnpm publish. The script receives environment variables describing the workspace being published.

The environment variables provided are:

  • RELEASE_IT_WORKSPACES_PATH_TO_WORKSPACE
  • RELEASE_IT_WORKSPACES_TAG
  • RELEASE_IT_WORKSPACES_ACCESS
  • RELEASE_IT_WORKSPACES_OTP
  • RELEASE_IT_WORKSPACES_DRY_RUN

When publishCommand is omitted, an appropriate npm or pnpm command is executed automatically.

{
  "release-it": {
    "plugins": {
      "@release-it-plugins/workspaces": {
        "publishCommand": "node publish.js"
      }
    }
  }
}

distTag

@release-it-plugins/workspaces uses the latest dist-tag when the released version is a stable release and the prereleaseId when it is a prerelease (e.g. beta for 1.0.0-beta.1). This is a good default setup, but there may be cases where you would like to specify a custom dist-tag to be used.

{
  "release-it": {
    "plugins": {
      "@release-it-plugins/workspaces": {
        "distTag": "lts"
      }
    }
  }
}

workspaces

The list of workspaces is gathered from the package.json in the current working directory. This is the same location that npm install/yarn install uses, and it is a great default for @release-it-plugins/workspaces. In some circumstances, the workspace settings that npm/yarn should use differ from the actual locations that are published. Most commonly this is due to a custom build script that emits the compiled and ready to publish packages into a different location (e.g. dist/packages/*).

{
  "release-it": {
    "plugins": {
      "@release-it-plugins/workspaces": {
        "workspaces": ["dist/packages/*"]
      }
    }
  }
}

This value replaces the value from package.json, and given the above configuration @release-it-plugins/workspaces would publish each package (that was not private) in dist/packages folder.

additionalManifests

versionUpdates

There are cases where you'd like to ensure JSON files other than your workspace packages package.jsons have their version property updated. For example, you may publish an alternate docs.json file in your published package.

{
  "release-it": {
    "plugins": {
      "@release-it-plugins/workspaces": {
        "additionalManifests": {
          "versionUpdates": ["dist/docs.json"]
      }
    }
  }
}

The default configuration is ['package.json'] to ensure that the top level package.jsons version is updated upon release.

dependencyUpdates

There are cases where you'd like to ensure files other than your workspace packages have their dependencies / devDependencies / optionalDependencies / peerDependencies updated but not also get a version bump. A great example is if you maintain a template package.json for consumers of your package(s). In that case, you would not want to bump its version property but you would want to ensure that any dependencies have been updated to match the newly published versions.

{
  "release-it": {
    "plugins": {
      "@release-it-plugins/workspaces": {
        "additionalManifests": {
          "dependencyUpdates": ["blueprints/*/package.json"]
      }
    }
  }
}

License

This project is licensed under the MIT License.

changelog

v5.0.2 (2025-06-19)

:bug: Bug Fix

Committers: 1

v5.0.1 (2025-06-19)

:bug: Bug Fix

Committers: 1

v5.0.0 (2025-06-18)

:boom: Breaking Change

  • #124 Support release-it 17, 18, and 19 (drop support for 14, 15, and 16). (@rwjblue)
  • #119 Drop support for Node < 20 (@rwjblue)

:rocket: Enhancement

:house: Internal

Committers: 1

v4.2.1 (2025-06-17)

:bug: Bug Fix

  • #120 fix(pnpm): Ensure pnpm install is ran after updating versions (@rwjblue)

Committers: 1

v4.2.0 (2024-01-15)

:bug: Bug Fix

Committers: 1

v4.1.0 (2024-01-15)

:rocket: Enhancement

:house: Internal

Committers: 2

v4.0.0 (2023-07-11)

:boom: Breaking Change

  • #106 Upgrades release-it to 16.x. Upgrades node to 16.x (@scalvert)

:rocket: Enhancement

:house: Internal

Committers: 2

v3.2.0 (2022-07-26)

:rocket: Enhancement

:bug: Bug Fix

  • #81 Bumps release-it to fix scoped context lookup (@scalvert)

Committers: 1

v3.1.0 (2022-07-21)

:rocket: Enhancement

Committers: 1

v3.0.0 (2022-07-20)

v3.0.0 (2022-07-20)

:boom: Breaking Change

  • #73 Refactor to support release-it@15 (ESM) (@refi93)

:bug: Bug Fix

:house: Internal

Committers: 2

v2.0.1 (2021-04-19)

:bug: Bug Fix

  • #53 Use the full relative path when npm publishing (fixes an issue with npm@7 publishing) (@nilzona)

Committers: 1

v2.0.0 (2020-10-20)

:boom: Breaking Change

  • #45 Drop Node 11 and 13 support. (@rwjblue)
  • #44 Make release-it a peer dependency (require host project to provide). (@rwjblue)
  • #43 Drop release-it@13 support. (@rwjblue)

:house: Internal

Committers: 2

v1.5.0 (2020-09-08)

:rocket: Enhancement

Committers: 1

v1.4.0 (2020-04-28)

:rocket: Enhancement

  • #35 Update the top level package.json version by default. (@rwjblue)

:memo: Documentation

  • #34 Add configuration summary to README.md. (@rwjblue)

Committers: 1

v1.3.1 (2020-04-27)

:bug: Bug Fix

  • #32 Ensure dependencyUpdates and versionUpdates can reference the same file. (@rwjblue)

:house: Internal

Committers: 1

v1.3.0 (2020-04-03)

:rocket: Enhancement

  • #30 Add logging output (primarily for --dry-run / --verbose). (@rwjblue)
  • #29 Add additionalManifests.versionUpdates option. (@rwjblue)

Committers: 1

v1.2.0 (2020-04-01)

:rocket: Enhancement

  • #26 Allow bumping versions in additional manifest files. (@rwjblue)

:house: Internal

  • #27 Avoid running CI for "pushes" on pull requests. (@rwjblue)

Committers: 1

v1.1.2 (2020-04-01)

:bug: Bug Fix

  • #25 Pass specific package paths to npm publish (avoid process.chdir). (@rwjblue)
  • #24 Ensure new version is updated appropriately in dependencies. (@rwjblue)
  • #22 Ensure prompts have access to required information. (@rwjblue)

:house: Internal

  • #23 Create unified set of plugin operations for test assertions. (@rwjblue)

Committers: 1

v1.1.1 (2020-03-31)

:bug: Bug Fix

  • #17 Do not list private packages in "should we publish" prompt. (@rwjblue)

:house: Internal

Committers: 1

v1.1.0 (2020-03-30)

:rocket: Enhancement

  • #16 Prompt if publishing scoped package fails with private error. (@rwjblue)

:house: Internal

Committers: 1

v1.0.2 (2020-03-29)

:bug: Bug Fix

Committers: 1

v1.0.1 (2020-03-27)

:bug: Bug Fix

Committers: 1

v1.0.0 (2020-03-27)

:rocket: Enhancement

  • #8 Refactor publishing process. (@rwjblue)
  • #1 Basic implementation of bump and publish methods (@scalvert)

:bug: Bug Fix

  • #11 Ensure any cross package dependency versions are updated. (@rwjblue)
  • #6 Leverage try/catch when bumping (to bubble unrelated errors) (@rwjblue)
  • #2 Fix bug in resolveWorkspaces. (@rwjblue)

:memo: Documentation

:house: Internal

  • #10 Update package.jsons directly (avoid npm version) (@rwjblue)
  • #7 Re-roll yarn.lock. (@rwjblue)
  • #3 Update prettier related packages to prettier@2 (@rwjblue)

Committers: 2