CODEWITHSUNDEEP
typescriptyarnpkgmonorepolernayarn-workspaces
MarTic
MarTic

Reputation: 835

How to manage multiple monorepos

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?

Upvotes: 6

Views: 1126

Answers (1)

Cody E
Cody E

Reputation: 189

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.

Upvotes: 2

Related Questions