EmDash CMS – Projekt-Bootstrap und Verzeichnislayout

Veröffentlicht am 2026-04-08 von Emdash Cms Everything

Für wen dieser Leitfaden ist

Nutzen Sie ihn, wenn Sie mit einem leeren Repository starten und eine Struktur brauchen, die Folgendes trägt:

• tägliche redaktionelle Content-Änderungen
• Frontend-Iteration ohne CMS-Annahmen zu brechen
• späteren Umzug von lokaler Entwicklung zu Cloudflare

Ziel ist nicht der cleverste Ordnerbaum, sondern langfristig niedrigere Wartungskosten.

Zuerst die Laufzeitentscheidung

Bevor Sie Dateien anlegen: Welche Laufzeit optimieren Sie in den nächsten 30 bis 90 Tagen?

• Node.js + SQLite für schnellstes lokales Onboarding und geringste operative Komplexität
• Cloudflare Workers + D1 + R2 für Produktions-SSR, verwalteten Speicher und engere Integration mit dem EmDash-Plugin-Modell

Wenn Ihr Team noch die Content-Strategie validiert, starten Sie mit Node.js und halten Sie von Tag eins an Cloudflare-taugliche Namen. So vermeiden Sie frühes Plattform-Lock-in und halten Migrationen einfach.

Empfohlenes Basis-Verzeichnislayout

your-emdash-site/
├── src/
│   ├── components/            # Nur wiederverwendbare UI-Bausteine
│   ├── layouts/               # Gemeinsame Page-Shells
│   ├── pages/                 # Astro-Routen
│   ├── lib/                   # Fachlogik und Integrationen
│   ├── styles/                # Globale und geteilte Style-Tokens
│   └── live.config.ts         # Live-Content-Collection-Mapping
├── seed/                      # Seed-Daten für Bootstrap/Demo
├── public/                    # Statische Assets (Favicons, Bilder)
├── docs/                      # Produktdokumentation und redaktioneller Content (MDX)
├── astro.config.mjs
├── package.json
├── tsconfig.json
└── emdash-env.d.ts

Wenn Ihr Projekt bereits utils/ statt lib/ nutzt, behalten Sie das vorerst. Umbenennen Sie erst, wenn klare Ownership-Regeln durchsetzbar sind.

Verzeichnis-Ownership

Die Struktur funktioniert nur mit explizitem Ownership:

• src/components: nur Präsentation; keine direkten DB- oder Storage-Aufrufe
• src/layouts: gemeinsame Rahmen (Head, Nav, Footer)
• src/pages: Routen-Komposition und Daten-Verdrahtung fürs Rendering
• src/lib: Geschäftsregeln, Datenadapter, plattformspezifischer Kleber
• seed: reproduzierbare Basis-Inhalte für neue Umgebungen

So vermeiden Sie die häufigste Drift: Utility-Code wird still zur Fachlogik.

Bootstrap-Pfad ohne Nacharbeit

Für Produktionsprojekte diese Reihenfolge:

1. Mit offiziellem Scaffold anlegen
2. Ein Template wählen (Blog, Marketing oder Portfolio)
3. Generierte Konventionen beibehalten, außer sie kollidieren mit einem klaren Team-Standard
4. Pro Schritt nur eine strukturelle Anpassung

Warum die Reihenfolge zählt: Die meisten Launch-Verzögerungen fehlen nicht an Features, sondern entstehen durch frühe strukturelle Abweichungen, die später Docs, Skripte und Onboarding brechen.

Empfohlene Bootstrap-Befehle

# Neues EmDash-CMS-Projekt scaffolden
npm create emdash@latest my-emdash-site
cd my-emdash-site

# Installieren und lokale Entwicklung starten
npm install
npm run dev

Häufige Anti-Patterns

1) Route-first ohne Content-Model

Seitenrouten bauen, bevor Collection- und Taxonomie-Form feststehen, verursacht teure Rewrites.

2) Deployment-Themen in UI-Ordner mischen

Keine deployment-spezifischen Skripte und Config-Helfer unter components oder pages. Plattformbelange gehören in Config-Dateien und src/lib.

3) Unbegrenzte utils-Ordner

Wenn alles in utils landet, bricht Auffindbarkeit zusammen. Benannte Domains in src/lib, z. B. src/lib/content, src/lib/media, src/lib/auth.

Definition of Done für die Ersteinrichtung

Bootstrap gilt erst als abgeschlossen, wenn:

• der lokale Dev-Server ohne manuelles Patchen läuft
• ein Beispiel-Content-Flow Ende-zu-Ende funktioniert
• Seed-Daten in einer frischen Umgebung importierbar sind
• der CI-Build ohne umgebungsspezifische Hacks durchläuft
• ein neuer Mitwirkender das Repo in unter zehn Minuten navigieren kann

Nächste Schritte

Wenn die Struktur steht:

1. Laufzeitwahl und Migrationskriterien im Repository dokumentieren
2. Namenskonventionen für Content-Typen festlegen, bevor das Volumen wächst
3. Deployment-Runbook für die gewählte Plattform umsetzen

Verzeichnisstruktur ist Architektur, kein Kosmetik-Thema. Früh festlegen spart später Wochen.