Merges

Configuration Merge Order

In our system, granular control over configurations is important. They are merged in a specific order, allowing different levels of configuration to define different fallbacks or defaults.

Definitions

• OpenAPI Service: This refers to a moleculer service that is using the OpenAPI mixin. Starting from the OpenAPI service configuration, we can define some default responses.
• Web Service: This refers to a service that is using the moleculer-web mixin. Here, you can define configurations specific to this web service.

Hierarchical Structure

The hierarchy of the configuration merges follows this order:

graph LR
    A[OpenAPI Service] --> B[Web Service]
    B --> C[Route]
    C --> D[Alias]
    D --> E[Service]
    E --> F[Action]

Loading

Successively:

• Route: After that, the route configuration comes into play.
• Alias: Then comes the alias configuration, which can be used for setting up shortcuts or easier access.
• Service: This allows for configuration settings specific to this service. (not valid for the services holding OpenApi service and moleculer-web)
• Action: The final layer of configuration is at the action level. Anything defined here will have the highest precedence.

Using False to Block Previous Definitions

If a setting is an object, it can be disabled by setting it to false in a subsequent configuration. This prevents the merge from advancing any further for the given property. However, there is a notable exception to this rule: the "tags" setting.

Special Case: "tags"

In the tags field within the 'openapi' object, you can achieve particular behaviors by setting its value to an array containing null and tags. If the array contains null followed by some tag values, this will "clear" any previous tags and only apply the tags specified after null.

Below is an example of this usage:

{
  openapi: {
    tags: [null, "myTag1", "myTag2"]
  }
}

In this case, any tags defined in preceding configurations will be discarded. Only "myTag1" and "myTag2" will be used.

This behaviour is unique to the tags field and is not applicable to other settings within the 'openapi' object. Remember, configurations are merged following the order specified in the hierarchy, with configurations defined at higher levels (closer to the action) overriding those defined at lower levels.