Config Configuration

12003

The framework provides powerful and extensible configuration capabilities, allowing for automatic merging of application, plugin, and framework configurations, with sequential overrides, and the ability to maintain different configurations based on the environment. The merged configuration can be directly obtained from app.config.

There are various solutions for configuration management, and some common approaches are listed below:

1. Use platform-managed configuration, where the current environment's configuration is included in the package during application build, and specified at startup. However, this approach does not allow for multiple deployments from a single build, and using configurations in local development environments can become cumbersome.
2. Use platform-managed configuration, where the current environment's configuration is passed in via environment variables at startup. This is a more elegant approach, but it places higher demands on operations and requires support from the deployment platform, while also facing similar pain points in the development environment.
3. Use code-managed configuration, where multiple environment configurations are added in the code, and the current environment's parameters are passed in at startup. However, this does not allow for global configuration and requires code modification.

We have chosen the last configuration approach, Configuration as Code, where changes to configurations should also be reviewed before release. The application package itself can be deployed in multiple environments, simply by specifying the runtime environment.

Multi-Environment Configuration

The framework supports loading configurations based on the environment, defining configuration files for multiple environments. For specific environments, please refer to Runtime Environment Configuration.

config
|- config.default.js
|- config.prod.js
|- config.unittest.js
`- config.local.js

config.default.js is the default configuration file, which will be loaded by all environments and is generally used as the default configuration file for the development environment.

When specifying env, both the default configuration and the corresponding named configuration file will be loaded. The named configuration and the default configuration will be merged (using extend2 for deep copy) into the final configuration, with named configuration items overriding the same-named configurations in the default configuration file. For example, the prod environment will load config.prod.js and config.default.js, where config.prod.js will override the same-named configurations in config.default.js.

Configuration Syntax

The configuration file returns an object that can override some of the framework's configurations, and applications can also place their business configurations here for easier management.

// Configure the directory for the logger file, with default logger configuration provided by the framework
module.exports = {
  logger: {
    dir: '/home/admin/logs/demoapp',
  },
};

The configuration file can also be simplified to the exports.key = value format:

exports.keys = 'my-cookie-secret-key';
exports.logger = {
  level: 'DEBUG',
};

The configuration file can also return a function that accepts the appInfo parameter:

// Place the logger directory under the code directory
const path = require('path');
module.exports = (appInfo) => {
  return {
    logger: {
      dir: path.join(appInfo.baseDir, 'logs'),
    },
  };
};

The built-in appInfo properties include:

| appInfo | Description |
|