One vs. many — Why we moved from multiple git repos to a monorepo and how we set it up
Mike Nikles

Hey, nice write-up! We also moved from a set of 40+ repos to a monorepo managed by Lerna recently, and our experience have been similar. Previously we would end up in dependency hell every time we made a change to base package — had to manually update dependencies in all services and dependent modules, not a pretty sight :) Now we can do branches and PRs accross different modules, deploy the whole product with all dependencies setup correctly and never have to think about which module we need to update in order to get the right package. A few drawbacks we encountered using Lerna:

  • using lerna publish from the CI is a bit clunky, as it adds a commit with the latest version, so we end up versioning constantly, and publishing to our private npm registry on every green build. Which is desirable, but the problem is the extra commit means developers need to push, then after a green build pull and rebase their changes to incorporate the CI commit;
  • if you use npm instead of yarn, you can do lerna bootstrap — hoist to get all common modules into a root node_modules folder;
  • we have the same setup, as in packages in packages folder, services in services folder. We decided to mark services as private, to avoid publishing them to our private npm repo, as we don’t need to require service packages at all, so we don’t use the @service- prefix