Monorepo

I've used a monorepo which consisted of two React packages (one of frontend only, and the other included a simple node server for SSR purposes).

The cool thing about this setup was being able to use a shared directory which included components/services/whatever that were used in both apps.

It was written in Typescript and I've created a base tsconfig file, as well as project specific tsconfigs which extended the base one (https://www.typescriptlang.org/docs/handbook/tsconfig-json.html#configuration-inheritance-with-extends). Proper path mapping was also crucial (especially for accessing the shared stuff easily - https://www.typescriptlang.org/docs/handbook/module-resolution.html#path-mapping).

Each project had it's own webpack configuration.

In my case there was one, common package.json file with all the dependencies and scripts - but in some cases it might be better to separate them and create one per package.

App structure (pretty much simplified here) looked like:

- package.json
- tsconfig.base.json
-packages
  - package_one
    - server
    - client
    - webpack
    - README.md
    - tsconfig.json
  - package_two
    - src
    - webpack
    - README.md
    - tsconfig.json
  - shared

I worked on a React/Node.js app that had the web app and a bunch of our custom node modules all in the same git repo (the app depended on the node modules... and we weren't allowed to publish those node modules anywhere on the Internet). We used yarn workspaces so the app could resolve those dependencies while we were developing, and then had a build that combined everything into a single deployable node project that you could run "yarn install" and "yarn start" on.

Originally we had each custom node module in a separate git repo and tried to manage it all with git submodules. It became a version-control nightmare until we switched to the monorepo.

I have a monorepo for my Backend and I'm really happy so far. I put some days of effort into abstracting away my Gitlab CI jobs and my actual modules just extend the base jobs and overwrite their path, so that CI can find the artifacts required for deployment. The advantage is you can do build caching across all your services/modules as they are using the same repo as well as caching of your docker images by recycling some layers in common, much optimization possibilities.

The biggest advantage for me is to have the core of my project as compact as possible to maintain control over everything all the time, plus the ability to have shared modules without going through an archive repository first.

My goal is to do infrastructure provisioning within my pipeline (ex. Kubernetes setup, creating some AWS resources) before deploying my services so that I can replicate and reconstruct my whole application at any point in time and setup staging environments easily.

I'm using Java with Quarkus/Gradle which lets you easily link modules through Gradle Multi Module Projects, with JS it's a different story. Others have recommended lerna, there is also https://bit.dev you can use for Web which lets you upload your components and share them between projects, but this doesn't require having a monorepo

Lerna (https://lerna.js.org/) works nice for non-Angular JS projects (also node), especially when using Yarn as your package manager.

There are some cases, however, you may want to consider other approaches:

• having a React config that is difficult to change – it was tricky to reconfigure WebPack when using the Create React App toolkit (maybe something has changed since then);
• non-Node back ends – then you'll probably need have a Lerna monorepo within some generic monorepo, also some back-end stacks don't work well with monorepoed front ends;
• not all CI/CD services work well with monorepoes – instead of building/publishing single packages, it may waste resources on rebuilding unchanged packages if not configured properly (and this configuration can be tedious, especially on CircleCI which I use daily).

Take a look at https://lerna.js.org/ we use this in a React project. Its been a while since we set it up but never really had any issues with it.

There is a list on that link of projects using Lerna to get an idea of folder structure.