Skip to content
🚝 A small wrapper around lerna that makes it easier to use in CI
Branch: master
Clone or download
allcontributors and msrose docs: add jakebolam as a contributor (#28)
* docs: update

* docs: update .all-contributorsrc
Latest commit 397bf80 May 17, 2019
Type Name Latest commit message Commit time
Failed to load latest commit information.
.circleci build: Deploy website from CircleCI (#21) Apr 25, 2019
__mocks__ Update tests (#10) Apr 25, 2019
docs docs: Add website (#19) Apr 25, 2019
src Add linting (#11) Apr 25, 2019
test Add linting (#11) Apr 25, 2019
website docs: Update website color (#23) Apr 26, 2019
.babelrc Feature/populate monodeploy with base files (#1) Apr 22, 2019
.eslintignore docs: Add website (#19) Apr 25, 2019
.eslintrc.js Add linting (#11) Apr 25, 2019
.gitignore build: Build website in CI (#20) Apr 25, 2019
.nvmrc Reorganize files (#6) Apr 24, 2019
.yvmrc Update package.json (#2) Apr 23, 2019 Add code of conduct (#13) Apr 25, 2019
LICENSE Initial commit Apr 22, 2019 docs: add jakebolam as a contributor (#28) May 17, 2019
greenkeeper.json Update greenkeeper.json (#26) Apr 27, 2019
yarn.lock docs: Add website (#19) Apr 25, 2019



npm CircleCI npm All Contributors Greenkeeper badge

A small wrapper around lerna that makes it easier to use in CI


yarn add --dev monodeploy


npm install --save-dev monodeploy

Why monodeploy?

As a monorepo manager, lerna is a great tool, but it's not necessarily easy to use in CI if you want to publish all your packages every master build. Here are some problems you might encounter:

  • Running lerna publish in CI pushes back to your git repository, which may fail if commits have been pushed to your master branch in the meantime.
  • lerna requires all package versions to be stored in your repository, in their respective package.json files, therefore it's not possible to simply skip pushing to git from CI by using the --no-push option when publishing.

monodeploy allows you to publish NPM packages from a monorepo in CI, using lerna, on every single master build, without storing your version numbers in your package.json files and without having CI commit back to your repo. We could argue back and forth about whether or not it's good idea to publish NPM packages every single build to master (maybe --canary builds would be better), and we could certainly agree that not storing version numbers in package.json files is confusing, but in some cases the benefits of such a scheme outweigh the shortcomings, and monodeploy is intended to suit those scenarios.

How does monodeploy work?

monodeploy uses the registry as the single source of truth for package version numbers. At a high level, it does the following:

  1. Use lerna to determine which packages need to be published
  2. Retrieve the latest versions of these packages from the registry
  3. Update the package.json files for these packages with the latest version numbers from the registry
  4. Use lerna to bump the package versions and publish to the registry without commiting to the repo or pushing to the remote
  5. Create git tags for each newly published package
  6. Output a JSON list of all packages in your monorepo, including their latest version numbers.


Thanks goes to these wonderful people (emoji key):

Michael Rose
Michael Rose

💻 ⚠️
Brendan Hall-Hern
Brendan Hall-Hern

Shouvik DCosta
Shouvik DCosta

Maryam Pazirandeh
Maryam Pazirandeh

Jake Bolam
Jake Bolam


This project follows the all-contributors specification. Contributions of any kind welcome!


Special thanks to Carol Skelly for donating the 'tophat' GitHub organization.

You can’t perform that action at this time.