Should environment variable values be normalized?

[CanadaHonk]

Eg: '0' -> 0, 'false' -> false. Suggested by @nicolo-ribaudo

[pi0]

Hi. Sharing some experience for doing this. For Nuxt users, we had been doing env value deserialization for couple of years using unjs/destr and it gave both positive and negative feedbacks.

I think for boolean type true|false, it would probably make sense.

Re numbers we had several user issues where tokens (intended to be string) looking like a number are wongly parsed. For example should an env with value 9100000000000001 should be parsed as number or string? (JSON.parse('9100000000000001') === 9100000000000000)

[ljharb]

From my experience maintaining npmjs.com/qs, as well as working with jquery's .data() API over decades, I think implicit deserialization is a nightmarish rat's nest of footguns, and it would be far safer and less surprising to have env vars only ever be strings when present.

[nicolo-ribaudo]

Just spent one hour trying to figure out why some code was working locally, and failing on our CI -- it turns out that something was setting an env var to "false" 🙃 babel/babel@b1ec607

When it comes to booleans, it's incredibly annoying because there is no easy conversion from a string to boolean: Boolean(x) will convert the string "false" to the boolean true, and JSON.parse(x) will throw when the env var is not defined.

If we want to avoid implicit deserialization, it could be explicit with an API like env(name, type):

const str = env("FOO");
const str2 = env("FOO", "string");
const bool = env("FOO", "boolean");
const num = env("FOO", "number");
const int = env("FOO", "bigint");

where the type definition would be

function env(name: string): string | undefined;
function env(name: string, type: "string"): string | undefined;
function env(name: string, type: "boolean"): boolean | undefined;
function env(name: string, type: "number"): number | undefined;
function env(name: string, type: "bigint"): bigint | undefined;
function env(name: string, type: unknown): string | boolean | number | bigint | undefined;

[pi0]

Small suggestion re future compatibility if env API adds more extensions maybe it could be like this:

env(name, { type: "boolean" })

[CanadaHonk]

Fwiw to note for future, I don't think we should worry about the API having an argument for a default value, instead allowing the user to do (... ?? defaultValue)/etc.