Skip to content
🚝 A small wrapper around lerna that makes it easier to use in CI
JavaScript CSS HTML
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
.circleci
__mocks__
docs
src
test
website
.all-contributorsrc docs: add lime-green as a contributor (#44) Jul 13, 2019
.babelrc
.codecov.yml
.eslintignore
.eslintrc.js
.gitignore
.nvmrc
.yvmrc
CODE_OF_CONDUCT.md
LICENSE Initial commit Apr 22, 2019
README.md
greenkeeper.json
package.json
yarn.lock chore: bump lerna version (#42) Jul 10, 2019

README.md

monodeploy

monodeploy

npm npm downloads CircleCI codecov All Contributors Greenkeeper badge

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

Installation

yarn add --dev monodeploy

or

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.

Contributors

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

📖
Emmanuel Ogbizi
Emmanuel Ogbizi

👀
Josh DM
Josh DM

💻 🚇

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

Credits

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

You can’t perform that action at this time.