
Validieren der Umgebungsvariablen-Nutzung in der Codebasis
Durchsuche deine Codebasis, um jede Umgebungsvariablen-Referenz zu erkennen. So kannst du fehlende, ungenutzte, doppelte und falsch verwendete Variablen frühzeitig erkennen, bevor sie Laufzeitfehler verursachen.
Erstklassige Unterstützung für SvelteKit, Next.js und Nuxt. Funktioniert außerdem gut in modernen JavaScript/TypeScript-Projekten und Frameworks wie Node.js und Vue – oder in jedem anderen Setup, in dem du einen zuverlässigen Vergleich von .env-Dateien benötigst.
✨ Vorgestellt in awesome-cli-apps – Eine kuratierte Liste großartiger CLI-Anwendungen

→ Siehe Capabilities-Dokumentation für Details dazu, was der Scanner prüft und wie er funktioniert.
--init)Generiere eine Standard-Konfigurationsdatei:
dotenv-diff --init
→ Siehe Konfigurationsdokumentation für weitere Details.
Integriere dotenv-diff einfach in deine Git-Hooks oder CI/CD-Pipelines, um die Konsistenz von Umgebungsvariablen durchzusetzen.
→ Siehe Git-Hooks-Dokumentation für weitere Details.
In SvelteKit-, Next.js- und Nuxt-Projekten erkennt dotenv-diff eine falsche Verwendung von Umgebungsvariablen, die für das jeweilige Framework spezifisch ist.
▸ Framework-Probleme (SvelteKit)
──────────────────────────────────────────────────────────────────────
PUBLIC_API_URL $env/dynamic/private
Variablen dürfen nicht
mit "PUBLIC_" beginnen
src/routes/+page.server.ts:3
──────────────────────────────────────────────────────────────────────
→ Siehe Framework-Dokumentation für weitere Details.
.env.example schreibenEine .env.example, die so geschrieben ist, dass sie für neue Teammitglieder leichter zu verstehen ist:
# Node-Umgebung (development, production, etc.)
# @optional
NODE_ENV=development
# Die öffentliche API-URL wird verwendet, um unser Backend aufzurufen
PUBLIC_API_URL=http://localhost:3000
# Temporäres Token für die Partner-API-Sandbox – wende dich an das Integrationsteam für ein neues
# @expire 2027-03-31
PARTNER_API_TOKEN=
→ Mehr lesen: Eine gute .env.example schreiben
Ein Scan vergleicht deinen Code mit einer einzigen Datei – daher bleibt jeder Schlüssel, den du zu .env hinzufügst und in .env.example vergisst, unsichtbar, bis ein neuer Mitwirkender das Repository klont. Drift-Warnungen erkennen genau das:
▸ Drift zwischen .env und .env.example
──────────────────────────────────────────────────────────────────────
STRIPE_SECRET nicht in .env.example dokumentiert
──────────────────────────────────────────────────────────────────────
Standardmäßig aktiviert; deaktivieren mit --no-drift-warnings.
→ Siehe Drift-Warnungen für weitere Details.
Füge deinen Umgebungsvariablen Ablauf-Metadaten hinzu, um Warnungen zu erhalten, wenn sie kurz vor dem Ablauf stehen. Zum Beispiel in deiner .env-Datei:
# @expire 2025-12-31
API_TOKEN=
→ Siehe Ablauf-Dokumentation für weitere Details.
Du kannst Warnungen zu bestimmten Umgebungsvariablen ignorieren, indem du Kommentare in deinem Code hinzufügst. Zum Beispiel:
const apiKey = process.env.API_KEY; // dotenv-diff-ignore
Das ist hilfreich, wenn du weißt, dass eine bestimmte Warnung in deinem Quellcode sicher ist.
→ Siehe Ignorieren-Kommentare-Dokumentation für weitere Details.
--baseline)Übernimm dotenv-diff in Projekte, die bereits bekannte Warnungen haben, indem du den aktuellen Zustand in einer Baseline-Datei aufzeichnest. Zukünftige Ausführungen melden nur neu aufgetretene Probleme:
dotenv-diff --baseline
→ Siehe Baseline-Dokumentation für weitere Details.
--explain)Untersuche eine bestimmte Umgebungsvariable, um zu sehen, wo sie definiert ist, wo sie in der Codebasis verwendet wird und welchen Gesamtstatus sie hat:
dotenv-diff --explain DATABASE_URL
→ Siehe --explain-Dokumentation für weitere Details.
In Monorepos mit mehreren Apps und Paketen kannst du gemeinsame Ordner einbeziehen:
{
"scripts": {
"dotenv-diff": "dotenv-diff --example .env.example --include-files '../../packages/**/*' --ignore VITE_MODE"
}
}
→ Siehe Monorepo-Dokumentation für weitere Details.
Dies wird:
0 → Keine Fehler1 → Fehler gefunden (oder Warnungen im strikten Modus)→ Siehe dotenv-diff-Dokumentation für die vollständige Dokumentation
Issues und Pull-Requests sind willkommen.
→ Siehe CONTRIBUTING für Details.
Dank an diese großartigen Personen für ihren Beitrag zu diesem Projekt:
Lizenziert unter der MIT-Lizenz.
Erstellt von chrilleweb