BoxLang 🚀 A New JVM Dynamic Language Learn More...
Storing secrets in source-controlled files is a bad idea, but we still need some way to provide these sensitive credentials or configuration values to our projects. This problem is exacerbated in development environments where we are running multiple servers at once. This package let's us solve this problem for servers started with CommandBox.
This package loads up local files as Java Properties for both CommandBox commands and servers. The usage is nearly identical, but with enough gotchas to warrant breaking them out in to separate sections.
One note about the
.envfile: Do not commit it to source control. Add it to your.gitignoreimmediately.
Another good tip is to create an
.env.examplefile that is source controlled that contains all the keys required in your.envfile but none of the values.
When loading up the CLI, this package will look for a
.env file in the directory where CommandBox is being
loaded or executed. If found it will take the key / value pairs found
in the file and store them as CommandBox environment variables. These
values are now available in any CommandBox command either using
systemSettings.getSystemSetting( name, defaultValue ),
or by using CommandBox's built-in
system variable expansion.:
echo ${myvar}
Any time you run a command, if there is a .env file in
the current working directory where the command was run, those vars
will be loaded into the environment context of that command only. This
is great for localized variables that only apply to a specific
project. Note, this feature only kicks in if you are on CommandBox 4.5
or higher.
When starting up a server, this package will look for a
.env file in the webroot of the server starting. If
found, it will take the key / value pairs found in the file and store
them as Java properties. These values are now available in your web
application using the java.lang.System object and the
getProperties() or getProperty(name,
defaultValue) methods (Note: the keys are case-sensitive).
To point to a custom properties file to be loaded in addition to the
convention .env file above, you can set a
dotenvFile key in your server.json or config
setting server.defaults.
server set dotenvFile=foo.properties
You can also set a comma-delimited list of paths using file globbing patterns.
# Load all properties files in the web root as well as foo.properties in the config folder.
server set dotenvFile=*.properties,config/foo.properties
When using CommandBox in multi-site mode (6.0.0+) any time a
.site.json file is read for a specific site, any existing
.env will be read from the web root of that site and used
for expanding any system setting placeholders in that site JSON file.
CommandBox will use a nested environment for loading this .env file so
any env var names declared here will not conflict with env vars in the
global sheel or loaded at the top server level or or any other sites.
None of the site-specific env vars will be passed to the running
server process. They are only used inside the .site.json.
When starting up the CLI, CommandBox will look for a
~/.box.env file. It will load the file's key / value
pairs as environment variables inside CommandBox.
If you change the contents of this file, you will need to reload your shell for the changes to take effect.
If you want to change the name of the global environment file, you can update your module settings:
config set modules.commandbox-dotenv.globalEnvFile = "~/.commandbox.env"
The file name .env can be overridden, if desired.
For instance, by running:
config set modules.commandbox-dotenv.fileName=env.properties
all your file names will need to be env.properties.
You can also set your example env file name:
config set modules.commandbox-dotenv.exampleFileName=env.properties
There is currently no way to provide a per-project override.
There are two levels of logging available. You can log to the
console every time an .env file has been loaded by
setting the printOnLoad setting to true.
config set modules.commandbox-dotenv.printOnLoad=true
You can get further output that shows you the name and value of every
variable that was loaded by setting the verbose setting
to true as well.
config set modules.commandbox-dotenv.verbose=true
The verbose setting will only kick in if
printOnLoad is also true.
When using environment variables, you will inevitably run in to a
situation where you lose time debugging a strange error only to find
that you haven't provided a value for a new environment variable. The
check command will check that all the keys in your
.env.example file exist in your .env file.
dotenv check
The filenames can be overridden with the envFileName and
envExampleFileName parameters to the command.
dotenv check envFileName=env.properties envExampleFileName=env.example.properties
You can reverse the check to ensure the .env.example
file has all the keys in your .env file by passing the
--reverse flag.
dotenv check --reverse
One great place to add this command is using CommandBox GitHooks.
{
"githooks": {
"preCommit": "dotenv check --reverse",
"postCheckout": "dotenv check",
"postMerge": "dotenv check"
}
}
This will prevent you from commiting code when you have
.env keys that are not in your .env.example
file. It will also check for any new keys in your
.env.example file and notify you of them after checking
out a new branch
Another great place to add this command is in your CI pipeline to avoid deploying a build with a missing environment variable.
Enabled by default is a preServerStart check. This will
run dotenv check for you and throw an error if the
.env file does not have all of the
.env.example keys. This is to help prevent you spending
precious time debugging your application just to find you are missing
an env key.
If you do not want this behavior, you can set the
checkEnvPreServerStart module setting to false.
box config set modules.commandbox-dotenv.checkEnvPreServerStart=false
Thanks to Dan Card and his commandbox-envfile library,
you can interact with your env file right from CommandBox. There are
four commands to help you out.
This shows the current .env file contents. You can pass an override envFileName or folder, if desired.
This gets the value of a key in the current .env file. You can pass an override envFileName or folder, if desired. Don't forget tab completion here to help you fill out the key names quickly!
This takes two arguments, a name and a value, and sets it in your current .env file. Current property names can be tab completed. You can pass an override envFileName or folder, if desired.
This command will inspect your .env.example file and help you fill
out the values in your .env file. Additionally, it can only prompt you
for new values using the --new flag. The
exampleFileName, envFileName, and folder can all be customized, if desired.
This command will load arbitrary properties files into your CommandBox environment. Useful for task runners where you need to load a shared environment file.
$
box install commandbox-dotenv