Actually I really like this approach. It sounds like a best practice to me.
I have library to read environment variables as application config. I was thinking to add it to the library, having an option like mandatoryKeys but then I left it to users to validate the keys. Maybe adding that option and making it mandatory to define could force this practice. If they don't want to validate the keys they'll have to define mandatoryKeys: [] for instance. I'll think about it.
Actually I really like this approach. It sounds like a best practice to me.
I have library to read environment variables as application config. I was thinking to add it to the library, having an option like
mandatoryKeys
but then I left it to users to validate the keys. Maybe adding that option and making it mandatory to define could force this practice. If they don't want to validate the keys they'll have to definemandatoryKeys: []
for instance. I'll think about it.yatki / read-env
🔧 Transform environment variables into JSON object with sanitized values.
read-env
Main purpose of this library is to allow developers to configure their applications with environment variables. See: a use case example.
What's New with v2.x🚀
separator
option,nested object constructions are possible.source
option allows you to use other objects, other thanprocess.env
Migrating from v1.x to v2.x
default
export is deprecated. Please use named exportreadEnv
as below:parse
option was renamed assanitize
.transformKey
option was renamed asformat
.ignoreInvalidJSON
,prefix
,filter
,Install
or
Basic
…Thanks for the tip.
Cheers, 🚀🖖