You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While the parser should not fail on the given input, I don't think it should treat it as a comment. As an example, Docker only support comments in .env files if the line starts with a #. If it does not, it's treated as a value.
This can be proven by creating a .env file with the above contents and then run the following
$ docker run --rm -it --env-file .env alpine:3.14 sh -c 'echo $SOME_ENV'useless # this isn't used
Yeah, right now LuckyEnv does the same as Docker: ENV["SOME_ENV"] == "useless # this isn't used". It was the dotenv shard that fails. It might be fixed by this point, but at the time that would throw an error.
So with that said, let me toss this at you and get your thoughts @kevinsjoberg. My plan is eventually that our .env files would look completely different and would not 1-1 with other dotenv parsers. See #1 for more on that. So, should this shard return "useless" and ignore the rest provided that you didn't do something like SOME_ENV="value # with comment"? Because in that instance it's obvious that you're wanting the string literal...
My plan is eventually that our .env files would look completely different and would not 1-1 with other dotenv parsers. See #1 for more on that.
I like the direction you're taking in #1. 🙂 On a parser level, I think it makes sense to keep compatibility with other Dotenv parsers for the sake of ergonomics. Depending on how deployment is setup, the "Lucky env" file would be a candidate for being used by tools such as Docker or Kubernetes.
The env parser bundled with Lucky fails on this:
Should this be something we should allow? 🤔
The text was updated successfully, but these errors were encountered: