# OSCD-Component monorepo
Date: 2023-06-16
## Status
Open
## Context
For OpenSCD/next we currently have a couple of components in different repositories. We will have more components like this in the future.
It's good to know that a monorepo is not the same as a monolith.
| Info | ||
|---|---|---|
| ||
A good monorepo is the opposite of monolithic! Read more about this and other misconceptions in the article on [“Misconceptions about Monorepos: Monorepo != Monolith”](https://blog.nrwl.io/misconceptions-about-monorepos-monorepo-monolith-df1250d4b03c "Misconceptions about Monorepos: Monorepo != 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/).
If we want a themable application where plugin authors can rely on a global style, we should make use of css variables. We can also make use of [Design Tokens](https://spectrum.adobe.com/page/design-tokens/).
With design tokens, we can generate css variables.
We can then override the Material css variables, so all the material components (mdc/mwc) will have the same look.
### Background
Related links:
- [Adobe Design tokens](https://spectrum.adobe.com/page/design-tokens/)
- [Design Tokens for dummies](https://uxdesign.cc/design-tokens-for-dummies-8acebf010d71)
- [Material Design Tokens](https://m3.material.io/foundations/design-tokens)
## Decision
T.B.D.
## Consequences
**OpenSCD mono repo**
=> disadvantages
=> less control on permissions