search

absxn / process-env-parser

Purpose-built utility to parse environment variables into safe runtime types in your TypeScript Node application
https://www.npmjs.com/package/@absxn/process-env-parser
17 stars 1 forks source link

Use the default value if the value is empty #1

Closed akheron closed 4 years ago

akheron commented 4 years ago

It would be nice to either use the default value if the environment variable's value is an empy string, or have a config option to do this.

I think making this the default behavior would make the most sense, because I don't think it's common to have a meaning in whether an environment variable is defined or not.

teijo commented 4 years ago

Hmm, good idea, though a bit tricky since it adds a corner case to existence. What if the value is space " "? It's pretty meaningless too, and it could slip through similar to "", slip as in the glue outside the application sets up the variables incorrectly.

What's your use case for having empty variable ("") indicate non-set vs not actually setting it? Is it some configuration file or external script that uses empty string as not-set / default?

akheron commented 4 years ago

Well yeah, kinda. I'm introducing process-env-parser to a project in which there are many developers who have these empty environment variables in their local development environment because of such external scripts. The scripts can be fixed to leave the empty values out, but then the developers need to run the scripts again to re-bootstrap their environment. It's not such a big deal, though, so if you think this is not a good idea feel free to close :)

It's always hard with strings when you essentially have two ways of representing nothing / no value: Either leaving the value not defined, or using the empty string.

teijo commented 4 years ago

The cases where I feel that having the special case for "" (to count for not set) being helpful, would be when explicitly running $ EMPTY= node app, the other one being a mistake, which I imagine could be pretty common, where you'd have $ VAR=${MISTAKENLY_UNSET_VAR} node app. That would fail if MISTAKENLY_UNSET_VAR was set/calculated in invalid manner.

If minimizing surprises is anyway the goal of the library, perhaps the change should be incorporated.

I'll try it out 👍

teijo commented 4 years ago

@akheron any thoughts on generalizing it to check envVar.trim().length === 0?

There could be something like $ USER="${FIRST} ${LAST}" node app, if FIRST and LAST were unset, the user would be " ", which probably shouldn't fly.

teijo commented 4 years ago

Someone can then make a PR in the future where you can pass {strict: true} that treats empty strings as is 😄