{"id":20805,"date":"2025-08-07T08:32:01","date_gmt":"2025-08-07T13:32:01","guid":{"rendered":"https:\/\/zocdoctech.wpenginepowered.com\/?p=20805"},"modified":"2025-12-22T14:42:51","modified_gmt":"2025-12-22T19:42:51","slug":"lerna-you-a-monorepo-the-nuts-and-bolts-of-building-a-ci-pipeline-with-lerna","status":"publish","type":"post","link":"https:\/\/www.zocdoc.com\/techblog\/lerna-you-a-monorepo-the-nuts-and-bolts-of-building-a-ci-pipeline-with-lerna\/","title":{"rendered":"Lerna You a Monorepo: The Nuts and Bolts of Building a CI Pipeline with Lerna"},"content":{"rendered":"\r\n

In part 1<\/strong><\/a>, we described the problems we set out to solve with a lerna monorepo. Part 2 describes how we created an actual monorepo and migrated an existing codebase into it and the lessons we learned.<\/p>\r\n\r\n\r\n\r\n

Spoiler: we like it, but it required some work to get to that point.<\/em><\/p>\r\n\r\n\r\n\r\n

The Pilot Project<\/h1>\r\n\r\n\r\n\r\n

The tool most commonly used in the Javascript ecosystem to manage monorepos is\u00a0Lerna<\/a>, which is what we ultimately decided to move forward with.<\/p>\r\n\r\n\r\n\r\n

We were a little hesitant to commit to a full-out migration without a trial period, so we decided on a mini-migration of about half a dozen components to make sure that a monorepo was the right solution.<\/p>\r\n\r\n\r\n\r\n

Our goals for the pilot migration were relatively straightforward:<\/p>\r\n\r\n\r\n\r\n

    \r\n
  1. Move half a dozen specific components and utils from our existing design system repo into a monorepo. Include small components, large components, components that depend on other components, and components we expect to be under active development so we can stress-test lerna.<\/li>\r\n\r\n\r\n\r\n
  2. Make sure unit testing, screenshot testing, interaction testing, and publishing packages are in good shape, and are scalable.<\/li>\r\n\r\n\r\n\r\n
  3. Find all repos that consume the migrated code from the legacy design system, and switch the imports to use the versions in the monorepo.<\/li>\r\n<\/ol>\r\n\r\n\r\n\r\n

    However, migrating a few components independently as individual packages is a bit more complicated than migrating a whole repository at once.<\/p>\r\n\r\n\r\n\r\n

    Code Organization<\/h1>\r\n\r\n\r\n\r\n

    It\u2019s common for the main source code of a non-monorepo repository to live in a\u00a0src\/<\/code>\u00a0directory. Instead, Lerna encourages you to use a\u00a0packages\u00a0<\/strong>directory. Generally the packages folder is a flat listing of every package in the repo, but we found that a bit more structure was ideal. Since this was common front-end code, we decided to break everything down into four categories, with the caveat that we could add more if there was a good case:<\/p>\r\n\r\n\r\n\r\n

      \r\n
    1. assets<\/strong>\u00a0for images\/icons\/fonts\/etc<\/li>\r\n\r\n\r\n\r\n
    2. components<\/strong>\u00a0for our react and javascript components<\/li>\r\n\r\n\r\n\r\n
    3. styles<\/strong>\u00a0for anything aesthetic<\/li>\r\n\r\n\r\n\r\n
    4. utils<\/strong>\u00a0as a catch-all for functions and constants we might want to be available from multiple places<\/li>\r\n<\/ol>\r\n\r\n\r\n\r\n

      This allowed us to create a structure and force developers to easily adhere to it. We found we could get lerna to follow this structure by setting the packages property in the\u00a0lerna.json<\/code>:<\/p>\r\n\r\n\r\n\r\n

      \r\n