清一清 tab... 兩個禮拜前還在日本時在 Hacker News 的「Show HN: From dotenv to dotenvx – better config management (dotenvx.com)」看到的東西，原文在推廣 dotenvx：「From dotenv to dotenvx: Next Generation Config Management」。
從 GitHub 的文件上可以看到幾個用法，一種是直接用，像是一般的 dotenv 的用法：
// index.js
require('@dotenvx/dotenvx').config()
console.log(`Hello ${process.env.HELLO}`)
另外一個是當 wrapper 用，像是這樣：
$ dotenvx run -- node index.js Hello World # with dotenvx > :-D
然後後者可以指定不同的 .env 多環境使用：
$ dotenvx run -f .env.production -- node index.js [dotenvx][info] loading env (1) from .env.production Hello production
另外還支援了 encrypt/decrypt 的能力降低 secret 的風險？不過這應該已經不是目前比較安全的方法了，這十年下來已經知道把 secret 放在環境變數裡太容易洩漏。
環境變數在呼叫外部程式時會被繼承，算是常見的 leaking 管道，另外就算不考慮外部程式，也會遇到環境變數算是一種全域變數，在寫測試時也很頭痛。
目前被提出來比較好的方法是把 secret 都放到 vault service 裡面，由 vault service 給一把讀取用的 API key，放進 dotenv 或是其他地方 (被稱為 secret zero)。
這樣這把 API key 去 vault service 抓取真正的 secret 放到程式內的物件取用 (像是資料庫的帳號密碼)，而不是環境變數。
這樣做的 threat model 在 Hacker News 上有對應的討論，另外 AWS 的服務其實也做了類似的事情：「Amazon EC2 的 IMDSv2 計畫」。
所以 dotenvx 大概就看看，有個印象就好？