Cue the first post about the exploit that leads to leaking AWS keys. I’ll wait.
This has been made by so many packages, they would be silly not to incorporate their work - licence dependent of course.
Edit - wait, not the exploit thing. The .env file thing
Better late than never. It’s going to take a while for people to get used to not needing the dotenv package.
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.envwas 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 inprocess.config; with the node version you can read from .config files (at least I hope you’ll be able to) but it goes toprocess.envwhether you like it or not.
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.
This was always a no-brainer imo. Love what node has been doing so far 👏
