Feature request: `import` to support .env/dotenv files
kevcube opened this issue · comments
Similar to #18
We use next.js, which depends on .env files.
Thankfully we are able to export in this format, but it would simplify things if we could also import in dotenv format.
hey there Kevin, thanks for the suggestion!
while we wait for more input on your feature request, in case you were looking for a workaround, have you considered using a combination of serializing dotenv's output + chamber's stdin import?
I believe this will work:
node -p 'JSON.stringify(require("dotenv").config().parsed)' | chamber import -explanation: chamber import understands yaml and JSON, and dotenv returns a JSON-serializable POJO of the parsed .env file.
more complete example:
## write some dummy values to .env to exercise parser edge cases
❯ > .env <<EOT
basic="foo"
multiline="my
...
multiline value
..."
comment="should be included" # should not be included
nocomment="is not # a comment"
EOT
## use node -p to print out a JSON-serialized representation of .env
❯ node -p 'JSON.stringify(require("dotenv").config().parsed)'
{"basic":"foo","multiline":"my\n...\nmultiline value\n...","comment":"should be included","nocomment":"is not # a comment"}
## or, pretty printed via jq for readability
❯ node -p 'JSON.stringify(require("dotenv").config().parsed)' | jq
{
"basic": "foo",
"multiline": "my\n...\nmultiline value\n...",
"comment": "should be included",
"nocomment": "is not # a comment"
}
## feed .env variables serialized to JSON into chamber via stdout => stdin
❯ node -p 'JSON.stringify(require("dotenv").config().parsed)' | chamber import -@knksmith57 thanks a bunch for the detailed workaround, yes I was aware of this as an option and I'm glad you basically coded it for me 😄
I was looking at the chamber's source code thinking "now ... WHERE do they process the Json?" and scratching my head until it became clear that the yaml library is capable of handling JSON and YAML.
I wrote some quick-and-dirty code that can handle this, tested and working for me, and saw the last in your contributor's guidelines that says not to feature PR without discussion first..
Well I already wrote the code and just wanna put it up for posterity but I'm open to any and all feedback/suggestions ❤
@knksmith57 when you say "while we wait for more input on your feature request", are you waiting for input from me?
nope! we're going to bring this to the next triage meeting to discuss —I'll let you know if we need more info or input but think I can adequately represent the request. thanks!
👋🏻 howdy @kevcube and @knksmith57 -- circling back on this while I'm going through the issues & PRs. I opened #372 (as an extension of #340) and spent some time with this today. Thank you for your suggestion and your patience. We're sorry about the time it's taken us to come back to this, but unfortunately I don't think this is something we should add directly into chamber.
dotenv files aren't standardized, and there are many conflicting, almost-but-not-quite identical parser implementations (with something on the order of 80-90% overlapping compatibility). What is considered "valid" in godotenv may not work quite the same if fed to Node's dotenv or the alternative dotenvy. But because there's no spec to validate against, it's impossible to say whether or not a given dotenv file is "valid" so this could potentially open up support liability in excess of our expectations down the road. It's a long shot, but overall support burden factors heavily into my judgement here.
Introducing additional parsable formats besides YAML (JSON just comes along for the ride since YAML is a superset of JSON) also means introducing additional logic to handle formats (which we saw in #340 and #372); right now it's a single outlier command flag, but this potentially opens the door for other structured formats (TOML and ini/properties immediately come to mind) and that's likely to bring additional flags and logic; I am not sure I want to open the door to carrying a dependency on parsers for every "reasonable" structured format -- all of these formats are pretty trivially reduced to key/value pairs represented as JSON or YAML already. I believe we're better able to serve the core functionality by maintaining a leaner interface whenever possible.
Sincerely, thank you for your suggestion. Like I said before, I'm very sorry we did not get back to this sooner. We really do appreciate your time and perspective on this.