.env can't be overridden by setting actual env variables in bash

[evrys]

It looks like miniflare reads a .env file but not the actual shell ENV-- is that intentional? I'm used to other implementations of .env always prioritizing the command-line vars, so that you can override them temporarily.

The particular use case I had was setting my FAUNA_ADMIN_KEY to something else to make sure it worked correctly against another database, like FAUNA_ADMIN_KEY=foo miniflare worker.js.

[mrbbot]

Hey! 👋 Yes, this is intentional. The problem with loading all environment variables (e.g. process.env) is that for service-worker type workers, they'd get set as global variables. This would include unrelated variables (e.g. HOME, USER, TERM) that would pollute the global scope.

I can think of a couple of solutions though. Miniflare could automatically bind environment variables starting with MINIFLARE_ (e.g. MINIFLARE_FAUNA_ADMIN_KEY=foo would bind FAUNA_ADMIN_KEY to foo in the worker).

Or Miniflare could check if keys in .env files were also in process.env, and prefer those values if they were. I'm not sure I like this solution though, as people might get confused why only some variables were being bound.

Let me know what you think 🙂

[evrys]

Ohh, avoiding polluting the global scope makes sense, yep. Checking .env against process.env would work well for most cases, though I agree that it might be pretty confusing for someone that variables not present in .env couldn't be defined. Probably good to have a note about it in the documentation, whichever way you decide to go there.

[DvnCodes]

This would be a great feature! Thanks for your work on this