Is it possible to form a multi-level monorepo (Q about tooling & structure)?

I'm in the research phase for converting my repos into a monorepo and further divide the codebase as of early 2023.

• I use TypeScript
• I have several servers and I want to divide them into microservices for further development
• I had several React frontends, I'll refactor them to another set

The final structure I want is something like this:

/project-root
  /desktop        # electron apps
  /documentation
  /examples
  /lib            # very common libs
  /mobile         # ionic apps
  /server         # node/express
    /lib          # libraries for server code
      /validation
      /...
    /gateway
    /api          # public api
    /ms-xxx       # microservices (Docker containers)
    /ms-yyy
    /...
  /web            # react apps
    /lib          # libraries for frontend code
      /uilib
      /...
    /webapp-1
    /webapp-2
    /...
  /website        # code for product website, possibly a CMS

I examined state-of-the-art tooling and these criteria seem to be plausible:

• Package manager: pnpm with workspaces
• Build tool: Vite
• Monorepo/packaging: I examined Nx and Turborepo/Turbopack but I find them restrictive, but I'm no expert on these so I might be wrong.

I would like to have multi-level tsconfig and package.json files (researching about Vite now), at the root (lint/Prettier etc), right under server and web, and of course under each app. I want servers and webapps use the same dependencies (e.g. same node/express/react etc versions).

• I tried Nx, but the @nrwl tooling versions were coming behind, resulting in dependency problems
• Turbo boilerplate is Next oriented, while Nx creates boilerplate that requires a lot of hacking. But unless you use them you need to hardcode your packages
• pnpm has issues with peer dependencies which I couldn't resolve now.

Except some simple examples, I don't see such larger code bases using these tools, hence the question:
Is this possible or am I getting this wrong?

Extending tsconfig files

> I would like to have multi-level tsconfig...

You can achieve this with extends in you config files (e.g. having a base tsconfig file that all your projects extend and customize, see docs for an example).

Avoiding duplicate dependencies

> I want servers and webapps use the same dependencies (e.g. same node/express/react etc versions).

While there's no way for one package.json to inherit from another like you can with tsconfig files, if you specify the same version numbers in all the package.json files for your different projects, package managers like npm will ensure that each dependency is installed once in a top-level node_modules folder (see the npm install --install-strategy flag in the docs).

Incremental builds for TypeScript projects

You might also be interested in TypeScript Project References which make it easy to specify the dependencies between the projects and get incremental builds.

When creating a new monorepo, I started with Lerna and Yarn (classic) Workspace and it wasn't the fastest but it was working... Nowadays, I always go with pnpm and the use of workspaces: protocol and similarly to previous answer by Wesley with a small difference in which I would suggest to use Lerna-Lite instead of Lerna. The main advantages with Lerna & Lerna-Lite is that they are both still easy to setup and offer great version and publish commands with optional use of Conventional Commits, so with very few setup of pnpm workspace and Lerna/Lerna-Lite you get easy publishing and automatically updated changelogs across the project.

When and why would you choose Lerna-Lite:

• nothing really compares to Lerna/Lerna-Lite version and publish with optional Conventional Commits. Some projects, like pnpm, use Changesets but it seems to require a bit more setup and I don't really like their changelogs (I prefer conventional changelogs).
• Lerna-Lite is much more modular than Lerna. Lerna is an all-in-one tools with 15 built-in commands with lots of dev dependencies, on the other hand Lerna-Lite has only 7 commands and they are nearly all optional (install only what you use).
• Lerna-Lite doesn't require Nx (the new Lerna >=6.x installs Nx behind the scene even if you don't use it, the only reason they chose to install Nx was to improve lerna run speed and with that Nx became a requirement in Lerna >=6.x, it's not surprising since Nrwl took over stewardship of Lerna)
• Lerna-Lite also works and actually uses pnpm workspace: and pnpm run on the workspace, the project started with npm workspaces but pnpm is way better so I switched it to pnpm (I'm the person who maintain Lerna-Lite). Using pnpm workspace is also great for making sure the lib works with pnpm & yarn workspace: protocol.
• Jest also switched to Lerna-Lite, they are using Yarn Berry workspace: protocol and are only interested in version and publish commands, so they found that Lerna-Lite was their best fit.
• you could easily add TurboRepo (or other tools) or simply use pnpm run (or just npm run --workspaces)
• Lerna-Lite can also auto update peer dependencies (though it's an opt-in option, see --allow-peer-dependencies-update), Lerna doesn't yet offer this option.

When would you use the original Lerna

• if you are already using Nx then it's probably better to use Lerna instead of Lerna-Lite since Lerna takes advantage, and uses, Nx internally while Lerna-Lite does not. Since it's maintained by Nrwl, you can be sure that their product Nx and Lerna are working well together.
• with Lerna, you could also install other tools like TurboRepo with Lerna but then you would end up installing (perhaps not knowingly) TurboRepo and Nx behind the scene, so... why would you do, and want, that to happen?
• Lerna is the original tool/lib, they have thousands of users and millions of downloads per month which is hundred times the size of Lerna-Lite

Summary

So in summary, for a monorepo I most often go with pnpm workspaces and Lerna-Lite, the setup process of both tools is quite simple and you don't end up installing a ton of dev dependencies when using both tools. The use of pnpm run is also what I usually go for, even if Lerna-Lite does offer lerna run optionally, and if you ever want to improve the speed of your run commands, then you can start looking at TurboRepo, Nx or other similar tools.

A last option might be to use pnpm directly to also publish versions, which is the approach used by many popular projects like Vite, Vue, ... these projects created their own tooling and when going with that route, you would probably end up with a bit more setup and complexity compare to a simpler pnpm + Lerna-Lite approach, but even then the idea is that it's also doable with a few external dependencies as well.

You may find Lerna useful for this structure.

Although I do prefer keeping packages separate and more self-contained. Working with Yarn V1 Workspaces to achieve a monorepo felt like more hassle than it was worth, particularly considering nested packaged conflicts that can occur (like with eslint, jest etc).

When looking at your structure, I would try to break things down and work with each package separately. For shared libraries, make them as generalized as possible so more packages can install them as dependencies.