[Feature Request]: Allow merging of multiple config files

[jakubledl]

Is your feature request related to a problem? Please describe.

In many projects, including now our own, one sees two or three different YAML configurations for UI5, each doing a different thing (one running with the mockserver middleware, a different one with the fiori local middleware &c.), but all sharing a lot of common information.

Describe the solution you'd like

Suppose I have e.g. ui5.yaml:

specVersion: "2.0"
metadata:
  name: ...
type: application
...

and mockserver.yaml:

server:
  customMiddleware:
    - name: sap-fe-mockserver
      beforeMiddleware: compression
      configuration:
        service:
          ...

I would like to be able to run e.g. ui5 serve --config ui5.yaml --config mockserver.yaml and have the two config files effectively merged into one configuration.

Describe alternatives you've considered

• catting the config files together and passing it to ui5, but besides being wonky, the UI5 CLI doesn't support passing configuration on stdin
• pasting the two configs into a new file using a pre-run NPM script, passing that to ui5 serve, deleting it afterwards (also not great)

[RandomByte]

Thanks for filing this feature request. Am I understanding it correctly that the two files contain configuration for the same project (the application)?

A ui5.yaml file can contain multiple configurations (e.g. multiple projects, extensions, etc), so we need to be careful which configurations should be merged.

[jakubledl]

Hello @RandomByte, that is correct! I understand further thought needs to be given to the question you mention, when one has multiple documents/configuration in a single document, but perhaps the most straightforward solution could be not to support this case (i.e. return an error when one of the files to be merged contains multiple YAML documents) and only allow merging of single-document files?

[matz3]

To merge multiple documents, the metadata.name could be used as key to identify the right document. I would at least expect those fields (specVersion, metadata, type) to be mandatory (also to be able to use the schema validation).