Beispielarbeiten · Software & Web-Apps
Monorepo: Workspace mit gemeinsamer Konfiguration und geprüften Abhängigkeiten
Für einen erfundenen Betrieb: ein pnpm-Workspace mit zwei Paketen, die sich über workspace-Verweise gegenseitig nutzen, mit gemeinsamer TypeScript-, ESLint- und Prettier-Konfiguration. Die Abhängigkeiten sind auf Zyklen geprüft; es wird nichts installiert.
Musterarbeit (Demo), kein Kundenauftrag. Gebaut als Probeaufgabe mit erfundenen Beispieldaten; die Prüfzahlen unten stammen aus dem automatischen Prüflauf und sind nicht geschönt.
Was gebaut wurde
- Zwei Pakete mit workspace-Verweisen, gemeinsame Konfiguration
- Abhängigkeitsgraph ohne Zyklus geprüft
- Gegenprobe mit zyklischer Abhängigkeit fällt durch
- Repository erfunden
Wie geprüft wurde
Automatischer Prüflauf vom 29.10.2026, aus dem Protokoll (Testdaten erfunden, Zahlen gemessen):
- Demo-Monorepo: 15 Dateien, 2 Pakete mit workspace:*-Abhaengigkeit, gemeinsame tsconfig/eslint/prettier, ohne Zyklus, kein Install
- 12 Pruefungen, Gegenprobe faellt durch
Grenzen
Was diese Probe nicht abdeckt, steht hier, damit niemand mehr erwartet:
- Geruest nur als Dateien erzeugt, nicht mit pnpm installiert und gebaut; Versionsnummern beim Einrichten pruefen
- Umbau eines bestehenden Repos (Verlauf, CI) ist eine eigene Absprache
- Fuer Nx oder Turborepo ist ein anderes Geruest noetig
Die Anleitung
# Monorepo-Geruest - Demo-Projekt Kornblume (erfunden)
Musterarbeit von GL Tools. Projekt und Paketnamen sind erfunden. Es wurde nichts installiert; die Dateien sind das Geruest.
## Aufbau
- `pnpm-workspace.yaml` - alle Ordner unter `packages/` sind Pakete
- `packages/shared` - gemeinsamer Code (`@kornblume/shared`)
- `packages/web` - Anwendung, nutzt `shared` ueber `workspace:*`
- `tsconfig.base.json` - gemeinsame TypeScript-Regeln; jedes Paket erbt sie und verweist ueber `references` auf seine Abhaengigkeiten
- `eslint.config.js`, `.prettierrc.json` - eine Konfiguration fuer alle
## Erste Schritte
```
corepack enable
pnpm install
pnpm build
pnpm --filter @kornblume/web build
pnpm --filter "...[origin/main]" test
```
`--filter` baut nur ein Paket (und was es braucht); der letzte Befehl testet nur Pakete, die seit `main` geaendert wurden.
## Neues Paket anlegen
1. Ordner `packages/<name>` mit `package.json` (Name `@kornblume/<name>`), `tsconfig.json` (erbt von `../../tsconfig.base.json`) und `src/`.
2. In `tsconfig.json` der Wurzel unter `references` eintragen.
3. Abhaengigkeit auf ein anderes Paket: `pnpm --filter @kornblume/web add @kornblume/<name>@workspace:*`.
## Regeln
- Keine Abhaengigkeit im Kreis: `shared` kennt `web` nicht.
- Versionen gemeinsamer Werkzeuge stehen nur im Wurzel-`package.json`.
- Vor dem Commit: `pnpm lint` und `pnpm typecheck`.
## Grenzen
Das Geruest ist nicht per `pnpm install` und Build ausgefuehrt; die Versionsnummern sind Vorschlaege und beim Einrichten zu pruefen.
So etwas für deinen Betrieb?
Beschreib kurz, was du brauchst. Du bekommst einen Festpreis, bevor ich anfange; ohne dein Ja passiert nichts.