View GitHub Project

Configuring Monodeploy

For a full list of CLI arguments, run:

yarn monodeploy --help

To fine-tune monodeploy, create a monodeploy.config.js file and invoke monodeploy via:

yarn monodeploy --config-file monodeploy.config.js

Note that monodeploy will automatically detect your monodeploy.config.js file if named correctly.

You can use a preset configuration as a basis for your monodeploy config, and add either additional config options or CLI flags to extend the preset. For example:

yarn monodeploy --dry-run --preset monodeploy/preset-recommended


A preset can be a filepath (relative or absolute) or the name of an installed npm package. You can pass a preset via the CLI argument or option directly in your config file. Other options are then merged with the values in the preset. In terms of precedence, CLI flags take highest precedence, followed by config file options, followed by preset values, and then finally the built-in defaults.

The preset should ultimately point to a file which exports a monodeploy configuration. You can also use any of the built-in presets.

yarn monodeploy --dry-run --preset monodeploy/preset-recommended

The "recommended" preset differs from the monodeploy default in that it will modify your package.json files, commit the changes, and then automatically push said changes to your remote git repository.

Configuration File

If you omit a property, a reasonable default will be used. Note that setting a property to null is not always the same as omitting the property (or setting it to undefined).

module.exports = {
preset: 'monodeploy/preset-recommended',
changelogFilename: '',


infer | public | restricted

Default: infer

This overrides the access defined in the publishConfig of individual workspaces. Set this to 'infer' to respect individual workspace configurations.


Default: No Default

Whether to resume publishing from a changeset. This option can only be set from the command line, and cannot be provided via a monodeploy.config.js file. This feature is not available yet. If you're interested in this feature, please leave comments on the GitHub Issue.


Default: false

Whether to automatically create a release commit, for use with persistVersions.


Default: "chore: release [skip ci]"

The commit message to use when autoCommit is enabled.


Default: No Default

The filename to write changelogs to, assuming a conventional changelog config has been set. Use '<packageDir>' to reference the cwd of an individual workspace.


Default: No Default

The filename to write the changeset to. This is a metadata file which after a monodeploy run, will contain change history useful for external scripts. Set to '-' to write to stdout.


Default: []

An array of micromatch globs which will be used to filter out modified files. You can use this to skip modifications to 'test files' as part of the 'how this package changed' determination.

string | RegExp[]

Default: []

An array of regular expressions which will be used to filter out commits from the explicit package bump detection. The patterns are matched against commits of the form: <sha> <newline> <body>

string | { name: string, key: string }

Default: Partial internal implementation (not recommended)

A conventional changelog config package name. This is required for changelog generation. This config determines the changelog format, as well as the version strategy determiner.


Default: cwd

The working directory to run all operations from. Defaults to the current working directory.


Default: false

If enabled, any operation performing a destructive action on an external system is skipped over. This includes publishing to NPM, committing to git, and execution of lifecycle scripts. Use dry run to preview publish changes, and to validate your configuration.


Default: false

By default, the changeset and changelog files are not written in dry run mode, as they constitute a change to an external system. Enable force write to write these change files, which can be useful for generating publish previews.


Default: last tagged commit

The base git ref to using as the starting point of package change discovery. If not set, this will default to the last tagged commit. You usually do not want to set this.


Default: HEAD

The git ref which marks the "end point" of package change discovery. This defaults to HEAD. You usually do not want to set this.


Default: false

Whether to push to the git remote. This works in conjunction with the git.tag and autoCommit options, thus allowing you to create the tags and release commit automatically while deferring the actual push.


Default: origin

The git remote name to push tags and the release commit to. Defaults to origin.


Default: true

Whether to create git tags to track the releases. It is useful to disable this when publishing to a test registry, where you do not want to modify the main git branch.


Default: 0 (No Limit)

The maximum number of packages whose lifecycle scripts can be run in parallel. Similar to concurrency in Lerna.


Default: 0 (Internal Implementation Detail)

The maximum number of package metadata to read from the NPM registry simultaneously. If no default is set, or set to 0, Monodeploy will use its discretion.


Default: 0 (Internal Implementation Detail)

The maximum number of packages to publish to the NPM registry simultaneously. We have seen issues in the past with too many concurrent writes for private registries. If no default is set, or set to 0, Monodeploy will use its discretion.


Default: false

By default the latest package versions upon which the version strategy is applied, is taken from the NPM registry. If noRegistry mode is enabled, the latest version is instead taken from the package.json files. This is incompatible with prerelease mode.

Deprecated: In favour of registryMode='manifest'.


Default: No Default

The manifest field name to use in workspace grouping. All packages within a group will always have the same version and git tag. If unset, all packages are versioned independently. Since the group is used for the git tag, it must not contain any characters not supported in a git tag.

You can use a '.' to access nested properties in the manifest file. For example, you can use '' to access the group property in your publishConfig.


Default: No Default

Package group specific settings. Note that if no packageGroupManifestField is set, each workspace is in its own group.


Default: false

Whether to persist package.json modifications, i.e. updating the dependency versions and the version field of each published workspace. Most publishing tools act as if this is enabled. It can be useful to disable version persistence if you do not want your CI environment to write back to your Git repository. Useful for runners like Jenkins.

string | ???[]

Default: []

An array of Monodeploy plugins. See the plugin section of the documentation for more information.


Default: false

Whether to run Monodeploy in Prerelease mode. In prerelease mode, versions are not published to the latest npm dist tag. This is meant for release candidates, and beta versions. Version strategy behaviour is also impacted by this mode.


Default: "rc"

The identifier to use in the prerelease tag. Defaults to 'rc' as in '1.0.0-rc.1'.


Default: "next"

The npm dist-tag to publish to in prerelease mode. Defaults to 'next'.


Default: "npm"

By default the latest package versions upon which the version strategy is applied is taken from the NPM registry (npm mode). If registryMode is set to 'manifest' the latest version is instead taken from the package.json files. Note that 'manifest' mode is incompatible with prerelease mode.

Can be either 'npm' or 'manifest'.


Default: Yarn Configuration

The NPM registry URL for fetching package information, and publishing packages. Note that this overrides any publishConfig.registryUrl or Yarn RC configuration.


Default: false

Whether to run the lifecycle scripts of the packages to publish in topological order, based on dependencies and peerDependencies. This excludes devDependencies from the graph.


Default: false

Similar to topological, however also consider devDependencies.