I wonder of this will also apply to npm then. I have a package that uses private packages which requires a personal access token to be present in env. Would make for nicer DX in our case.
dotenv has lots of features and I doubt node will try to match all of them.
The builtin node feature needs you to specify .env files as parameters to the node executable and puts values in process.env, that’s it. It’s great if that’s all you need.
With dotenv (which should’ve been called dotini) you can choose a file (any file, not just .env) to parse programatically, you can parse variables, you can specify the encoding and the override behavior, you can enable debugging, you can put the values in a different variable from process.env, you can do decryption, and it supports multiline values.
Last but not least, process.env was supposed to contain actual environment variables. Patching it with values from config files and mixing up the two concepts is a mistake – but at least dotenv lets you avoid it. With dotenv you can read from .config and put the values in process.config; with the node version you can read from .config files (at least I hope you’ll be able to) but it goes to process.env whether you like it or not.
Add comment