Briefly: from the beginning I had defined a .env inside the repo which got sourced along with any other supplied .env file at generation time. This was incredibly convenient, especially when building and testing locally. However, I never really liked that for the SITE_* variables, which were more or less required for the Full Opinionated Experience™, there was the potential to just have the mostly-useless ones hanging out.
And more frustratingly, because the .env was always sourced it would override anything defined at runtime e.g. SITE_URL=http://domain.tld bic .
This work fixes all that up by leaving an effectively-empty repo .env and having any defaults defined ${VAR:-default}-style in bic itself and simply printing a warning message if the important SITE_* aren't defined. Further, if someone wanted to define a variable in their .envand have it be overridable at runtime this can be done with
VAR="${VAR:-default}"
My motivation to keep the repo .env around is maybe I'll want it in the future e.g. some build metadata. Alternatively, I could use the aforementioned syntax to define the optional config (BUILD_DIR, DATE_FORMAT, SALT, and TIMEZONE) but as it stands I'd rather leave those in the source code.
mfossen
commented
1 year ago
This closes #13.
Briefly: from the beginning I had defined a
.envinside the repo which gotsourced along with any other supplied.envfile at generation time. This was incredibly convenient, especially when building and testing locally. However, I never really liked that for theSITE_*variables, which were more or less required for the Full Opinionated Experience™, there was the potential to just have the mostly-useless ones hanging out.And more frustratingly, because the
.envwas always sourced it would override anything defined at runtime e.g.SITE_URL=http://domain.tld bic .This work fixes all that up by leaving an effectively-empty repo
.envand having any defaults defined${VAR:-default}-style in bic itself and simply printing a warning message if the importantSITE_*aren't defined. Further, if someone wanted to define a variable in their.envand have it be overridable at runtime this can be done withMy motivation to keep the repo
.envaround is maybe I'll want it in the future e.g. some build metadata. Alternatively, I could use the aforementioned syntax to define the optional config (BUILD_DIR,DATE_FORMAT,SALT, andTIMEZONE) but as it stands I'd rather leave those in the source code.