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.
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.
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.