Search code examples
reactjsreact-bootstraplernamonorepo

lerna monorepo package structure

I am building a monorepo for a suite of React apps, and common library code. One of the packages would be a component library. 

packages
  app1
  app2
  common-ui
    alert
    button

I'm pretty new to the whole React/node ecosystem.

I've looked at a lot of actual UI library examples - react-bootstrap, material-design-components-react, etc.

It seems I would want to have each component in the common-ui lib to be distributed as single files, so that they can be cherry-picked when imported into a consuming app.

react-bootsrap does this by using babel to build the "lib". They build into a browser distributable, a commonjs lib, and an ES lib.

material-design-components-react does this by having their component lib itself by a lerna monorepo, with each component having its own package.json, and I believe they use webpack to build each component individually.

So my first question is,

  1. Is a structure like material-design-components-react in my common-ui folder - kind of a monorepo within a monorepo possible?

Or would I have to restructure:

packages
  app1
  app2
  alert
  button

My second question is,

  1. Which design is recommended by the community for a component library within a major monorepo? This must be a common structure developers have to solve when they have many client apps with common libraries. A package per common-ui component seems like a lot of overhead, but of course they have scripts to help out.
Solution

  • Is a structure like material-design-components-react in my common-ui folder - kind of a monorepo within a monorepo possible?

    Yes it's possible. But keep in mind, you and those libraries have very different requirements. You can think of your monorepo as small projects developed in same company., which are depending on similar 3rd party libraries and they follow same linting, testing etc.

    Which design is recommended by the community for a component library within a major monorepo? This must be a common structure developers have to solve when they have many client apps with common libraries. A package per common-ui component seems like a lot of overhead, but of course they have scripts to help out.

    First structure with 3 packages is most common way to start your repository/project.

    In your case, I wouldn't recommend to divide your ux-library into single files. Your apps will likely use most of your ux-library and probably you won't have as much components as material or bootstrap has. Moreover, if you'd ever reach that point in your library, you can separate them later. For reference you can also check how lodash is publishing each of their functions. It's not different than your case (assuming you won't publish any fonts/images etc.).