Closed JalilArfaoui closed 2 years ago
...thinking out loud here but... ...forking this repository to put some specific LMEL code might make more sense than adding some of those specific here... :thinking:
In my humble opinion LMEL is yet another environment... So I think it doesn't make much sense to duplicate the env variables, we should rather create yet another env file.
Even if it’s common practice, I’m not sure about having all those .env files anyway (https://github.com/motdotla/dotenv#faq) … But that is true that overriding values feels better than creating multiples ones … So I created à env.lmel
that overrides others .env
files … check it out
...thinking out loud here but... ...forking this repository to put some specific LMEL code might make more sense than adding some of those specific here... thinking
A fork that we would have to keep in sync in the future … would that still be a fork ?
About not commiting env files, you are absolutely right! On a server side environment we usually put all our little secrets in there...
But here, client side, we abuse the env system as a configuration system, and yes, we're not alone in this, if I recall correctly the loadEnv
function was even heavily inspired by nextjs env system.
:tada: This PR is included in version 3.91.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:
Closes #1149 Closes #1151