- Ein Next-Generation-Tool zur Verwaltung von Umgebungsvariablen, das die Grenzen des bisherigen
.env/.env.example-Ansatzes überwindet und Zusammenarbeit, AI, Sicherheit und Typsicherheit zugleich löst
- Mit
.env.schema wird das Schema der Umgebungsvariablen zentral verwaltet; anders als bei .env.example gibt es keine Sorge mehr über Abweichungen zwischen Realität und Beispiel
- Über @env-spec-Dekorator-Kommentare lassen sich verschiedene Informationen wie Schema, Typ, Validierung, Beispiele, Sensitivität und externe Secret-Verwaltung deklarativ in
.env-Dateien ergänzen
@required, @type=string, @sensitive, @example usw.
- Starke Validierung: Fehlerhafte Konfigurationen bzw. fehlende Eingaben werden sofort mit klaren Meldungen angezeigt (präventive Blockierung noch vor der Runtime)
- Schema-basierte automatische Typgenerierung sorgt beim Zugriff auf Umgebungsvariablen im Code für Typsicherheit und IDE-Intellisense-Unterstützung
- Sicherheit: Automatisches Maskieren sensibler Informationen (Logs/Konsole), Erkennung von Leaks in gebündelten Clients/Responses
- Mehrere Umgebungen und Overrides: Unterstützung für komplexe Umgebungs-Setups mit Standardwerten, umgebungsspezifischen Dateien, per Git ignorierten persönlichen Werten sowie der Kombination mit Prozess-Env
- Externe Secret-Integration: Dynamisches Laden von Secrets auf Kommando-Basis wie 1Password und
exec; Plugin-Support, lokale Verschlüsselung und Team-Vaults folgen in Kürze
- Sprach- und runtime-unabhängig: Nicht nur für JS/TS, sondern validierte Envs können auch in jede Sprache und jeden Prozess injiziert werden, z. B. mit
varlock run -- python my.py
- Kann dotenv vollständig ersetzen: Schon wenn nur der dotenv-Import durch varlock ersetzt wird, stehen sofort Funktionen wie Validierung, automatische Typgenerierung, mehr Sicherheit sowie Multi-Environment-/Secret-Integration zur Verfügung
2 Kommentare
Bedeutet das, dass
.env.schemain.gitignoreaufgenommen werden sollte?Ah … also werden die Informationen in
.envabgelegt und von.env.schemaeingelesen.