Deserialize config into type

[jchannon]

Have you considered providing an option something like the below that allows strongly typed config?

import {config} from "https://deno.land/x/dotenv/mod.ts";

const appConfig = config<MyAppConfig>({ safe: true });

console.log(appConfig.MySecret);
console.log(appConfig.TwitterApiKey);

#.env file
MySecret=
TWITTERAPIKey=

type MyAppConfig = {
  MySecret:string
  TwitterApiKey:string
}

[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 it is done in Typescript, makes so more sense to kick some types

Again, I can try and develop this, but my PRs are not getting reviewed. If anyone can get ahold of the author — I would gladly take on and do this feature

[pasha-bolokhov]

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 you have to do

const appConfig = config() as MyAppConfig;

which does not really check anything — or you would have to provide the list of variables to it in some way, e.g.:

const appConfig = config<MyAppConfig>({ safe: true }, ["MySecret", "TwitterApiKey"]);

At this point I don't know if it makes a lot of sense to implement it this way, because you would have to maintain such a list of variables in sync with your configuration interface MyAppConfig

Any suggestions are welcome on the matter

[LiamKarlMitchell]

related? https://github.com/pietvanzoen/deno-dotenv/issues/36 Everything is a string even booleans.

[pasha-bolokhov]

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 is essentially "emulates" the behaviour of Shell. This allows you to define environment variables, and do certain operations on them (in future) — such as composing them into a longer string. But again, strings only. After you've got your string, you're free to interpret it in whatever way. People who open a .env file pretty much expect to see a Shell script. That's the only way to keep it consistent between the implementations of dotenv for different languages, runtimes etc