Configuration File Merging

[x80486]

I would like to propose an enhancement that will minimize the need to repeat common keys across different configuration files, making it easier to manage configurations.

The idea is to implement a merging strategy for configuration files. For instance, config.json should be the base, and if there is an environment-specific configuration file, config.prod.json, the system should merge these files. The merging process must take into priority the keys defined in the environment-specific file, allowing for easy overrides without duplicating common configuration keys.

This is not something new. Many modern configuration management systems adopt this merging strategy, aligning this approach with common practices.

[System-Glitch]

Hello and thank you for your suggestion. Major changes on the configuration package are planned for v6 already and your idea would be a nice addition.

Could you provide some usage examples and describe your ideal implementation of this feature from a framework user standpoint?

[x80486]

It is important to define the origins of the configuration sources from which configuration values are retrieved. This includes configuration files, environment variables, system properties, and perhaps some more. Depending on the complexity, it is advisable to establish a well-defined chain of resolution, which can lead to interesting use cases.

In my experience, the resolution order should be:

1. Environment variables
2. System properties — essentially, anything that can be set on the command-line
3. Configuration settings — the actual values defined within the configuration files

The primary reason for merging these configuration files is that Goyave already has a notion of running modes, although not quite strictly enforced — that would be another plus with lots of potential. This concept aligns well and simplifies the overall configuration management. Currently, there is a need to duplicate some configuration settings. Here is a simple example:

// config.json — common to all
{
  "app": {
    "name": "goyave-sandbox"
  }
}

// config.dev.json — used only for development
{
  "app": {
    "debug": true,
    "name": "goyave-sandbox", // Merged value
    "profile": "dev"
  },
  "server": {
    "debug": true
  }
}

// config.test.json — used only when the application runs tests
{
  "app": {
    "name": "goyave-sandbox", // Merged value
    "profile": "test"
  }
}

// config.prod.json — used only when the application runs as an executable
{
  "app": {
    "name": "goyave-sandbox", // Merged value
    "profile": "prod"
  },
  "server": {
    "host": "0.0.0.0"
  }
}

Another advantage when enforcing running modes (e.g.: normal, dev, and test) is the ability to enable or disable specific settings for each mode, thereby simplifying the final configuration and reducing conflicts. For instance, the server.debug setting could be automatically configured by Goyave when the application runs in dev mode (regardless of the profile in use, which usually aligns with the deployemnt environments. However, if the user specifies a value in config.prod.json, it will take precedence. This behavior differs from settings defined in config.json, which would not override the prod configuration. This is merely a suggestion regarding the subject; I am not advocating for a specific implementation.

Overall, I believe the current implementation is quite close to this idea.

Additionally, a useful feature would be the ability to override certain keys using environment variables. For example, consider the database configuration. Currently, the approach is to define defaults and use an environment variable to specify the values. While this method works, if Goyave were to recognize that DATABASE_OPTIONS also resolves to database.options, it would be more efficient to set DATABASE_OPTIONS at deployment time if changes are necessary. This approach avoids the need for a round of changes, testing, deployment, and promotion.