A node JS env and configuration loader with typescript support. Build in support to load with respect to your environment, dev, prod etc

yarn add @xelgrp/configu
or
npm install @xelgrp/configu

This package currently supports loading properties files.

NOTE: This library supports configuration files that must be terminated by the extensions to determine its type.

• .ini, .properties: Properties files
• .yml, .yaml: Yaml files (Coming Soon)
• .json: Json configuration files (Coming Soon)

To load a configuration;

import { loadConfig } from '@xelgrp/configu';

interface AppConfig {
  host: string;
  port: string;
  dbPass?: string;
  dbUser: string;
}

const defaultConfigs = {
  host: 'localhost',
  port: 4040,
  dbUser: 'root'
}

// export function to use in loading later
export const getConfig = (): AppConfig => loadConfig<AppConfig>('app.ini', defaultConfigs);

export const config = getConfig();

This package loads Configurations in such a way that, the previous config will serve as variables for the next, override fields in next config file or will become additional fields in the configuration

Considering an app.ini configurations to load, variable loading takes place in the following order;

• process.env -> app.development.local.ini -> app.development.ini -> app.local.ini -> app.ini & process.env
• process.env -> app.production.local.ini -> app.production.ini -> app.local.ini -> app.ini & process.env
• process.env -> app.test.local.ini -> app.test.ini -> app.local.ini -> app.ini & process.env

Configuration variables are loaded from the app.**.ini files in such a way as to match the current environment. E.g. When NODE_ENV=development, the app.development.ini files are loaded along side the app.ini file and environment variables.

The NODE_ENV can be changed by any file by setting the NODE_ENV variable. This NODE_ENV variable always defaults to development.

process.env is loaded at the start to serve as variables for next configurations, it is again loaded at the end together with the base file so if it was overwritten along the load chain, it will still serve as a final source of truth.

Usually you would not want to commit your .local. files as they may contain variables that do not need committing, like usernames and passwords normally you will pass them through environment variables at deployment.

NOTE: All config files must be one directory

This project is MIT Licensed - see the LICENSE.md file for details