⏺️ Dotenv implementation for Scala sbt builds. Configures environment for local development.

sbt-dotenv

build Current Version Scala Steward badge License

sbt plugin to load environment variables from .env into the JVM System Environment for local development.

Storing configuration in the environment is one of the tenets of a twelve-factor app. Anything that is likely to change between deployment environments–such as resource handles for databases or credentials for external services–should be extracted from the code into environment variables.

But it is not always practical to set environment variables on development machines or continuous integration servers where multiple projects are run. sbt-dotenv loads variables from a .env file into ENV when the environment is bootstrapped.

sbt-dotenv is intended to be used in development.

Installation

sbt-dotenv is published for sbt 1.3.9 and above. To start using it add the following to your plugins.sbt:

addSbtPlugin("nl.gn0s1s" % "sbt-dotenv" % "3.0.0")

That's it - as soon as you start using sbt the environment is prepared.

Note that the group id has changed from au.com.onegeek to nl.gn0s1s.

Apple Silicon (M1 chips)

When on Apple Silicon (M1 chips), make sure to use sbt 1.6.0 or higher.

Usage

Create a .env file in the root of your project with some environment specific settings. For example, you might want to set a Mongo DB port to 17017 if it's installed by Homebrew.

vi .env

# this is an example .env file, comments like this will be ignored
URL_HOST=my-service.example.org # trailing comments are ignored too!

# you can export variables like a regular shell script
export URL_PORT=1234

# variables can be quoted
URL_PATH="/my-content#body"

# variable expansion is supported
URL=http://$SERVICE_HOST:${SERVICE_PORT}${URL_PATH}

# these will work with sbt-dotenv, but won't work with `source .env`
MY.VARIABLE=1
MY-OTHER-VARIABLE=2

# multiline variables work too
MY_CERT="-----BEGIN CERTIFICATE-----
123456789qwertyuiopasdfghjklzxcvbnm
-----END CERTIFICATE-----
"

# heredocs aren't supported!

Variable expansion of the form $FOO and ${FOO} is supported based on the values in .env or the system environment.

Change file name

It is possible to override the default file name .env. It will be treated as an absolute path if it starts with a /, and as a relative path to base directory of this project otherwise.

ThisBuild  / envFileName := "dotenv"

Use file to define environment for tests

It is possible to use same of alternative file to provide an environment for tests:

Test / envFileName := "test.env" // optional

Test / envVars := (Test / envFromFile).value

and integration tests:

IntegrationTest / envFileName := "test.env" // optional

IntegrationTest / envVars := (IntegrationTest / envFromFile).value

"Illegal reflective access" warnings and exceptions

On java versions 9 and up this plugin will give "illegal reflective access"-warnings. Java versions 16 and up turns the warnings into exceptions.

These can be avoided by starting sbt with these extra java options:

--illegal-access=deny --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED

The options can also be added to the .sbtopts-file:

-J--add-opens=java.base/java.util=ALL-UNNAMED
-J--add-opens=java.base/java.lang=ALL-UNNAMED

or in the .jvmopts-file:

--add-opens=java.base/java.util=ALL-UNNAMED
--add-opens=java.base/java.lang=ALL-UNNAMED

Should I commit my .env file?

It is recommended that you store development-only settings in your .env file, and commit it to your repository. Make sure that all your credentials for your development environment are different from your other deployments. This makes it easy for other developers to get started on your project, without compromising your credentials for other environments.

License

The code is available under the MIT license.