Migrate app configs from LB3 and centralize app configs

[f-w]

LoopBack 3 use case

LB3 configs are centralized in following 3 file sets with a predefined override precedence

• /server/config.(<env>|local.)js(on)
• /server/datasources.(<env>|local.)js(on)
• /server/middleware.(<env>|local.)js(on)

I created a notification microservice software based on LB3. I provide default configs in (config|datasources|middleware).js(on). Users customize their installations to fit their needs by creating corresponding local config files which are merged with and taking precedence over mine.

To minimize migration effort for my users, I would like to reuse the LB3 config files and preserve override precedence. However, LB4 configs are dispersed into bindings by design. There are no centralized config files and no easy way for config overriding.

With binding alias, it is feasible to centralize configs in LB4. I believe this is a common migration use case. LB4 can and should implement a standardized approach. For starter, following is my code snippet to import ApplicationConfig from files config.(<env>|local.)js(on) preserving override precedence. What's left is to create binding alias for common LB configs such as restApiRoot, host, port etc.

...
import * as _ from 'lodash';

export class MyApplication extends BootMixin(
  ServiceMixin(RepositoryMixin(RestApplication)),
) {
  constructor(options: ApplicationConfig = {}) {
    let configFiles = [
      'config.json',
      'config.js',
      'config.local.json',
      'config.local.js',
    ];
    if (process.env.NODE_ENV) {
      configFiles = configFiles.concat([
        `config.${process.env.NODE_ENV}.json`,
        `config.${process.env.NODE_ENV}.js`,
      ]);
    }
    for (const configFile of configFiles) {
      const f = path.join(__dirname, configFile);
      if (fs.existsSync(f)) {
        _.mergeWith(options, require(f), (t, s) => {
          if (_.isArray(t)) {
            return s;
          }
        });
      }
    }
    super(options);
    ...
  }
  ...
}

[achrinza]

Loosely related: #5332

[f-w]

#5332 is not specific to migration. It lacks binding aliasing.