How to manage multiple monorepos

Question

In our projects we have multiple monorepos used across whole company. The problem is, that we have for example monorepo-A and monorepo-B and monorepo-B uses components from monorepo-A (this is unchangable).

For example, the same team is developing monorepo-A and monorepo-B. Monorepo-B is a monorepo with final products (real output for a server, web pages) while monorepo-A is only multiple projects used in monorepo-B and in other monorepos used by other teams.

The problem is, when the team is developing monorepo-A and monorepo-B at the same time and change something in monorepo-A, the developer needs to deploy it first to be able try it in monorepo-B.

So there is a way with yarn link but that's not so much comfortable and there could be conflicts with packages.

Is there better way how to handle this situation for local development without publishing the code? There is a simle structure (not real, only for demonstation):

monorepo-a/
   packages/
      components/     (uses types)
      schemas/        (uses types)
      types/
   lerna.json
   package.json
   tsconfig.json

monorepo-b/
   packages/
      web-app/        (uses monorepo-a/packages/components)
      server/         (uses monorepo-a/packages/schemas)
      types/
   lerna.json
   package.json
   tsconfig.json

As a developer, I would like to change something in monorepo-A/packages/components and be able to use it immediately without build in monorepo-b/packages/web-app. But because they aren't in the same workspace I can't use paths in tsconfig.json or workspaces in package.json or something from lerna. Is there a way without publishing it even to local repository?

Walkover

I don't know how it works with yarn but with npm couldn't you just use npm install ../monorepo-a/packages/whatever ? That would create a symbolic link on your disk but if you gitignore node_modules (I'm sure you did that) it should be no problem. – Upset

Answer 1

Consider creating an enterprise NPM registry. It will absorb some resources as you migrate but is probably the most scalable solution, as it allows you to treat your internal dependencies with all your normal NPM tooling.

This will allow each mono repo to publish each child package which is great for reducing coupling across your code base and strictly define the role of each package.

Dg