3 ms·

Even if you don't set any values in your env files (although why not set some non-sensitive defaults) you can still benefit from the schema and validation that

Even if you don't set any values in your env files (although why not set some non-sensitive defaults) you can still benefit from the schema and validation that varlock provides. Imagine every public docker container had an .env.schema which was validated on startup, instead of scattered info about the available env vars in their readme.

0xbadcafebee 1y ago
Environment variables are a non-standard, limited form of transferring data. Depending on the platform, they may be case-insensitive, there are reserved words, size limits, naming rules, restricted charsets, etc. And their values are always strings. So having a schema on an environment variable isn't very useful, unless you do things like dynamic typing and type assumptions (which run into bugs). It's not a bad idea to have an opinionated library that defines some restrictions on environment variables, but the applications will always need to add more restrictions that your library has thought of. Schemas are application-specific. Applications all deal with data types differently. Some data types (defined in schemas) even use transforms and complex custom algorithms before their data is validated. So it's better to let the application handle schemas directly on an as-needed basis. All of that can be done independent of environment variables. Just make a library that validates data types, and pass your environment variables (or any data, from anywhere) to it. This is better not only because you can validate any kind of data, but you can load your data from places other than environment variables (from disk, from database, etc). This kind of general abstraction is more useful for general purpose computing, rather than a complex solution tailored for only one use case. Finally: A schema isn't a replacement for documentation. Just because you have a technical document that defines what data is allowed in a variable, doesn't mean that somebody then knows what the hell that thing does - what it affects, when it should or shouldn't be used, etc. Documentation is for humans, schemas are for computers.

0xbadcafebee 1y ago

Environment variables are a non-standard, limited form of transferring data. Depending on the platform, they may be case-insensitive, there are reserved words, size limits, naming rules, restricted charsets, etc. And their values are always strings. So having a schema on an environment variable isn't very useful, unless you do things like dynamic typing and type assumptions (which run into bugs). It's not a bad idea to have an opinionated library that defines some restrictions on environment variables, but the applications will always need to add more restrictions that your library has thought of. Schemas are application-specific. Applications all deal with data types differently. Some data types (defined in schemas) even use transforms and complex custom algorithms before their data is validated. So it's better to let the application handle schemas directly on an as-needed basis. All of that can be done independent of environment variables. Just make a library that validates data types, and pass your environment variables (or any data, from anywhere) to it. This is better not only because you can validate any kind of data, but you can load your data from places other than environment variables (from disk, from database, etc). This kind of general abstraction is more useful for general purpose computing, rather than a complex solution tailored for only one use case. Finally: A schema isn't a replacement for documentation. Just because you have a technical document that defines what data is allowed in a variable, doesn't mean that somebody then knows what the hell that thing does - what it affects, when it should or shouldn't be used, etc. Documentation is for humans, schemas are for computers.