pasha-bolokhov

That would be indeed a very reasonable thing to do, I agree. The roots of this package are coming from Node, where nobody could care less about types. Now that...

Here is the trouble with this issue. Type information is not stored at the runtime, so `config()` won't be able to check the presence or absence of variables. So either...

Not really. If you, or whoever, wants to have booleans — why just not consider regular json format? You'll also have your undefines, and nulls and integers. What `dotenv` does...

I just totally missed your idea Yes, I should do that — totally agree with you about the renaming. Although, it would be a breaking change… — is it still...

System env import works one way currently — that is, `dotenv` exports (if it was configured to) the config as environment variables, but ignores what already exists in the environment....

This is a neat idea, and I don't mind looking into this, as this follows the general logic to enable some `Shell` functionality to those `.env` files. Obviously, not all...

Is that really an issue? I mean, people can have many different names for their `env` files: `.env.test`, `.env.ci` and `.env.local` and various different combinations — it is not really...

Would be interesting to see how _Node_ implemented it. I mean it's all straightforward except where do you get the current _mode_ from?

I've never seen it being used. But it's not that we can't use it. We can use `NODE_ENV` just for the sake of getting the current running mode. Can also...

Just to mention, I did not notice it having been implemented in `Node`. If anyone has, lemme know, it would be good to follow the same pattern. If they haven't,...