Using dotenvx for our config management

Cristal
1

Hello all,

I’d like to propose the use of dotenvx for our configuration values management.

How do we handle configuration values currently?

For now, we have very little configuration variables (only two to configure web and realtime server ports). Note that I’m not discussing the backend configurations located in config.json files.
We handle default values manually. This lead to code duplication which is not great. We could define our own module to handle this, but I believe reusing an existing library is a better option.

Pros of using dotenvx:

  • by the creator of dotenv
  • regularly maintained
  • BSD 3-Clause License
  • allows for variable interpolation (see example below)
  • allows for configuration overload (see example below)

Example:

index.ts

import dotenv from "@dotenvx/dotenvx"

dotenv.config({
  path: [".env", ".env.development"], ## Configuration are read from right to left, if a variable is found in `.env.development` the value in `.env` won't be used
  overload: true
})

console.log(process.env.HW) ## Prints the value of the HW

.env

HELLO=Hello
HW="${HELLO} from .env"

.env.development

HW="${HELLO} from .env.development"

Execution result

[dotenvx@1.21.1] injecting env (2) from .env, .env.development
Hello from .env.development

Notice how:

  • HW is found in .env.development
  • ${HELLO} is replaced by the value of HELLOfrom.env`

What would it change for Cristal?

  • All the configuration values and their default value could be centralized in .env
  • Developer can define a .env.development file (adding to .gitignore) to define local settings without risking pushing them on master by accident
  • Test setup could define their own configuration with test values (e.g., Loading...)

WDYT?
Thanks

2

+1

Thanks,
Marius