Export to .json rather than .env

[samsch]

What's the possibility of including an option to create a JSON file (e.g., config.json) rather than an .env file?

[b3ross]

Not sure - what's the use case?

[samsch]

Env vars (mainly "real" system env vars, but also injected by dotenv to a lesser extent) aren't considered safe to use by all parts of the ecosystem. A plain gitignored json file is more provably safe to use.

Taking a peek at the serialization code, it looks like the functionality itself would be simple enough to add. I'm not entirely sure how to make it an option to use though. Maybe it would make more sense as a forked package.

[b3ross]

Yeah it would be super trivial to add, just would kinda be weird to add given that this repo is called "dotenvi". I would be curious about the exact use case you have so I can see whether it makes sense to try to generalize this repo to support more use cases like yours.

Env vars (mainly "real" system env vars, but also injected by dotenv to a lesser extent) aren't considered safe to use by all parts of the ecosystem.

Can you give a specific example?

[b3ross]

In theory, I agree with you about environment variables being a little less safe, but they're also simpler. So, I'd prefer a specific example to motivate the discussion.

[samsch]

The idea applies to any application, such as right now I'm working with fairly "normal" Node/Express web app.

The issue of using env vars comes from system env vars being global and frequently logged by default. They don't have the kind of safe defaults to protect sensitive data. When using a .env file, that might be avoidable, but since you're still using the env var access within the app, it's not obvious that system-level env vars shouldn't be used with the app. There may also be tools which read process.env and log it during a crash, not expecting it to contain sensitive data.

As for simplicity, with a json output from dotenvi, the only additional complexity would be using const config = require('./config.json'); instead of process.env, which is a little more typing, but fewer global variables and more explicit.

[joepie91]

There may also be tools which read process.env and log it during a crash, not expecting it to contain sensitive data.

Additionally, environment variables are frequently inherited by child processes, which themselves may have such behaviour (because they, too, do not assume environment variables to be sensitive information - and they shouldn't have gotten that information in the first place).

[b3ross]

Yeah dotenv generally accepts those known deficiencies in the interest of simplicity, but sure, I threw in support for you guys.

[b3ross]

:tada: This issue has been resolved in version 0.8.0 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket:

[samsch]

Awesome, thanks!