Local .env support for Environment Config overrides

[supermario]

Folks often complain about accidentally committing src/Env.elm.

Ideally we should be able to have:

• a valid src/Env.elm with purely test or dummy values
• support for an optional .env where with lamdera live
  • any defined values in .env that match an Env.* config item name, override its value
  • any changes to .env live reload as expected

Considerations for a good design:

• Can we make this delightful, such that you can't accidentally typo an Env.elm config name in .env, and not realise you haven't overriden what you thought you did?

[tibastral]

That's super helpful.

And what about a Test environment too ?
Because for now, there isn't a difference between test and dev.

[MartinSStewart]

Can we make this delightful, such that you can't accidentally typo an Env.elm config name in .env, and not realise you haven't overriden what you thought you did?

We could check for .env values that don't have a corresponding Env.elm value?

[supermario]

We could check for .env values that don't have a corresponding Env.elm value?

.env may be used for other non-Lamdera env vars as it's a more general mechanism, so I don't think it'll be that easy.

And what about a Test environment too

Not opposed, but that should be a separate issue.

[hansallis]

Maybe.. if there's a .env file, then we could require every values defined in Env.elm to also be present in .env? That would exclude the scenario where you're using a .env for other purposes though.

[sjalq]

Well if iiuc, it's a compiler step of some sort that changes the Env.elm file in deployment when we edit stuff on the Dashboard?

This essentially allows us to alter global variables available "ergonomically" everywhere?
Weaknesses atm is:

1. The original needs to be populated with believable values. (ending up in git as a result)
2. FE and BE vars aren't differentiated at compile time or by the linter.
3. The dashboard is somewhat confusing when I alter things or toggle public and private.
4. Seems to require a recompile step for any changes correct?

What is the most Lamdera thing we can do in the least amount of steps (or maybe even by deleting steps)?

Random ideas (not necessarily compatible):

1. Make a Env type and decoders. Read ENVs encode and decode them; very safe, likely ridiculous to implement. Terrible for noob confusion.
2. Split into FEnv.elm and BEnv.elm. Removes quite a bit of noob confusion on the first deploy.
3. Make Env.elm be of the format

myNiceVar = "INEXPRESSIBLE_IN_ELM_CAUSE_CAPS_VARNAME_GOES_HERE" -- finds the var in the string in vars and fills it in

4. Make Env.elm be of the format

we_only_find_all_caps_var = "" -- fills in WE_ONLY_FIND_ALL_CAPS_VARS form vars

Personally, I would prefer {2, 4} as a compiler step. That likely would also simplify whatever mischief the dashboard is complicit in. Deletes the need to differentiate at deploy time between FE and BE.
Some set of rules likely needed to sanitize what is actually in the vars to not break the elm string.