Яким чином налаштовувати конфігурацію додатків у Node.js?

Дванадцятифакторний маніфест стверджує, що для належної конфігурації веб-застосунків необхідно використовувати змінні середовища. У Node.js для локальної розробки прийнято використання пакету dotenv. Його завдання полягає в зчитуванні файлу .env та встановленні значень в process.env. У середовищах, відмінних від локального, цей пакет не є необхідним, оскільки існують сучасні підходи для розгортання Node.js не викорістовують .env.

Добрим тоном є перевірка змінних середовища при запуску. Для цього довгий час я використовував dotenv-safe, який є обгорткою навколо dotenv. Додатковою його функцією є перевірка того, що всі змінні з .env.example визначені. Цього було достатньо для моїх проєктів. Тому мені не здається доцільним перевіряти, наприклад, чи є DB_PORT цілим числом або чи є DB_URL дійсним рядком підключення, як це пропонує документація @nestjs/config. Config - це сінглтон, який ви не будете мокувати у тестах.

Але повернемося до dotenv-safe. Його не оновлювали протягом 4 років. Тому замість нього я використовую такий код у config.ts:
import { readFileSync } from 'node:fs';
import { join } from 'node:path';

import { config, parse } from 'dotenv';

config({ path: join(__dirname, '..', '.env') });
const missedEnvironmentVariables = Object.keys(parse(readFileSync(join(__dirname, '..', '.env.example')))).filter((exampleKey) => !process.env[exampleKey]);
if (missedEnvironmentVariables.length > 0) throw new Error(`${missedEnvironmentVariables.join(', ')} not configured`);

Уважний читач помітить у цьому коді виклик readFileSync, що не рекомендується використовувати. А розуміючий побачить цей виклик readFileSync двічі.

Але незабаром цей типовий код у моїх проєктах зміниться. Справа в тому, що у версії 20 Node.js можна буде припинити використовувати dotenv. Зараз активно обговорюється add built-in .env file support. Це є з коробки в Deno/Bun та скоро буде в Node.js. Докладний розгляд цієї фічі я зроблю, коли вона піде в реліз.