Нещодавно мій менті запитав, чому я попросив його відмовитися від використання
znv (zod + env) і замінити його на використання dotenv-safe та безпосередньо zod. Тож, моя відповідь на це така:1️⃣ Ваш додаток під час запуску має перевіряти наявність environment-змінних. Детальніше у 12 factor app. Якщо якась із змінних не вказана, не можна використовувати значення за замовчуванням. Замість цього необхідно викинути помилку, щоб аварійно завершити роботу. Це допоможе уникнути людських помилок, коли при релізі на продакшн забули додати нову env змінну, а default value призведе до некоректної роботи нової функції.
2️⃣ Як single source of truth про потрібні вашому додатку змінні слід використовувати
.env.example. Цей файл слугує документацією та його ми зберігаємо у корні репозиторію. На рівні коду dotenv-safe (який є обгорткою над dotenv) зчитає ваш .env.example та порівняє з process.env. 3️⃣ Потім у вашему config-service можна трансформувати interface ProcessEnv extends Dict<string>, тобто process.env['VAR_NAME'] має тільки string | undefined значення. та валідувати значення за допомогою
zod, чи як вам подобається. Тому використання
znv має наступні проблеми:👎 погіршує DevEx, бо замість
.env.example потрібно дивитися у код👎
znv дозволяє використовувати значення за замовчуванням