config-process organizes hierarchical configurations for your app configurations.
Configure typescript projects, fullt support typescript interfaces.
It lets you define a set of process configuration parameters, and extend them for different environments (development, qa, staging, production, etc.).
It plays nicely with any deployment mechanisem (docker , k8s , env vars , etc.. ), details in motivation section.
config-process comes with a basic implementation of configuration manager.
The configuration manager asynchronously loads plugins, each plugin uses different methods of configuration loading.
This configuration manager:
- Allows to use any built in or custom configuration plugins.
- Allows to control the order of loading plugins.
- Allows to control the hierarchy in which variables will be overidden.
- Comes with a built in boolean/number/json getters.
- Fully support asynchronous loading - perfect for fetching remote config from a remote server.
- Comes with some strong default to enable strong ease of use.
- Tiny with zero dependencies.
- Fully supports
dotenvfiles so it's hassle free to move from
Configuration load order ≠ hierarchy
Configuration load order can influence on if/which next configuration loader will be used. Configuration hierarchy influence on the order that the values will be merged into a single value.
NODE_ENV VS ENVIRONMENT
Some of the built-in plugins use
NODE_ENV to determine the environment the code is running.
The problem with
NODE_ENV is that some libs may act defferntlly according to
NODE_ENV value which may cause undesired results.
Therefore, the built-in plugins first try to use
ENVIRONMENT and only than use
It's also possible to change this behavior to first load a custom key instead of
ENVIRONMENT by setting
envKey to any desired key.
It's encourged that all plugins made to use this approach.
Simple - Default usage
By default the
config-process will try to use plugins by the following order:
Which means that by default values will be determined by the following hierarchy:
REQUEST_TIMEOUT=100 node server.js
; processConfig.get'REQUEST_TIMEOUT' , 'number'
In Node.JS echo system there are a dozen of popular conifguration modules. The most standard modules in the echo system has at least one of the following problems:
- Some depends on a file that needs to be switched during deployment, this requires some build specific logic to be applied as a result same image cannot be used to all environments
- Some don't provide casting, as a result when a value is being set by the environments, as an environment variable, it will always be a
Stringthis will require the application to manually cast it every time consumed.
- Some provides nesting in configuartion files, which makes it harder to be overidden by real environment variables.
- Some are not customisable, allows only it's openion of usage.