is there a way to make cfconfig env vars mandatory, i.e. blow chunks and exit if they aren't defined? docker has

{PWD:?pwd_env_var_must_be_defined}

If dotenv is installed, it will compare .env to env.example and make sure .env has everything in the example when you try to start a commandbox server (and complains if they aren't all there) but I don't know any other way to make them required (outside of custom shell scripts that check for them... if you're using docker)

I really hate that behaviour. Comparing wit an example, yuck, which makes the sample file an essential part of the setup. But it can be disabled though that's the best part 😀

If dotenv is installed, it will compare .env to .env.example and make sure .env has everything in the example

I didn’t know that! Cool!!

I've always found it pretty useful. I usually populate env.example with local dev data (as long as it isn't sensitive info) and commit that... then other developers can just run

dotenv populate

to create their .env files based on env.example. As it prompts for each value, they can just hit enter on all/most of the defaults.

I use this task runner in my builds to check files against .env.example - it even pulls down docker compose stacks from portainer to check them as well if you need to - so you dont push code without the envs in docker ready for you - https://www.forgebox.io/view/commandbox-stackChecker

If you have some package it makes sense to provide sample data. Imho it doesn't make sense to force you to change sample data to get a server up and running. Checking sample data should be an option, not a default. I think a zillion linux packages provide sample data but not one I know of forces you to use it. I guess i just don't lijke the naming convention, just don't call it a sample if you HAVE to use it

The examples are the values, you can take them as is or change them but the keys are required. .env generally isn't just sample data though, it's actual config info needed for your application to run. database connection info, s3 connection info, environment, etc.

It is an example, but if you are going to try and build something to validate against, why create another thing, now you have a .env file, and .env.example and a .env.constraints file... it's handy, you can override it... but not having it used to waste HOURS of my life. There are a few cases where I wish it was more flexible, but then its up to me to have .env.example.stg and .env.example.prod etc

It's also based on how node handles it.

It is handy but as said not my preferred default. I wasted lots of time just to realize it was there in newer versions of dotenv. But that's true of more ‘handy’ defauts in the coldbox templates