Context

It turns out that putting everything in a separate repositories has too many disadvantages e.g.:

• Key management
• Userrights
• Doing updates (e.g. library updates)

The initial idea was that this will help the maintenance of the software. It turns out that a maintainer has a group of repository in practice.

Decision

It's good to know that a monorepo is not the same as a monolith. 

There are 3 types of monorepos:

* Integrated Repos
* Package-based Repos
* Standalone Apps

Solution

For OSCD-Components, we should make use of the Package-based Repo.
Each component has it's own `package.json` File and can be individually developed, tested, compiled and published.

A good approach for monorepos is [`Lerna`](https://lerna.js.org/), in combination with [`Nx`](https://nx.dev). Other possible tools are [`TurboRepo`](https://turbo.build/) and [`Rush`](https://rushjs.io/).

It's good to know that a monorepo is not the same as a monolith. 

There are 3 types of monorepos:

* Integrated Repos
* Package-based Repos
* Standalone Apps

Core plugins can be grouped together in multiple monorepos

...

• Material (https://github.com/material-components/material-components-web)
• Shoelace (https://github.com/shoelace-style/shoelace)
• Helsinki Design System (https://github.com/City-of-Helsinki/helsinki-design-system)
• NL Design System (https://github.com/nl-design-system/example)
• Etc.

Decision

...

Consequences

Disadvantages for combining different packages into a monorepo

• A monorepo has less authorization rules.
  • If you can access one package in the monorepo, you can access them all
• Git history will become more cluttered in a monorepo
• Maintainership on a single package in a monorepo can become more of a hassle

...

=> disadvantages

=> less control on permissions

It turns out that putting everything in a seperate repositories has too many disadvantages.

...