Externalize overrides for localConfig.json

[offtherailz]

Description

Actually MapStore has no way to externalize configurations for localConfig.json.
The server where MapStore is installed may need specific configurations (e.g. auth rules, catalog services, cors settings, specific URLs).
To do this setting the localConfig.json must be edited. This has a series of cons:

• Any update of the application will reset the changes
• versioning of localConfig.json should be platform indipendent.

To allow externalization/customization we (me and @mbarto ) propose the following:

• MapStore should load 2 files instead of one:
  • localConfig.json
  • configOverrides.json
• configOverrides.json contains the changes to apply to localConfig.json and is added to the project, empty by default.
• The configOverrides.json file path can be intercepted by the MS back-end, if a env MS_CONFIG_OVERRIDES_FILE is defined. If so, the back-end will provide the external file instead of the local one.

configOverrides.json definition

This file should allow to apply simple changes to the localConfig.json.

Typical attributes to override are:

• root variables (printUrl, geoStoreUrl, bingApiKey, mapquestApiKey....)
• authenticationRules array of rules.
• initialState allow to configure the initial state of the application (e.g. initialState.defaultState.catalog.default.Services
• plugins: arrays of plugin configs (strings or object)

plugins: {
desktop: ["PluginName1", {name:"PluginName2", cfg: {someattribute: "someValue}]
}

configOverrides.json entries should allow to override all the properties.

One of the existing languages is:

JSON Patch

One way to express the changes can be JSON Patch RFC6902. There are many implementation in many languages (now we are interested only to JavaScript of course).
This language allow to do insert, update, delete, replace operations on a JSON.

Limitations of JSON Patch

Typically the overrides could be some changes to the plugins configuration.
The current plugin configuration look like this:

This mean that we may need to find the plugin (that can be expressed as string or object) and replace/add some configuration). The index of the element in the array may cange, and I didn't find any kind of "find and replace" functionality in jsonpatch.

So we may need to do a custom technique to replace configurations in array that supports some kind of search and replace rule.
An alternative is to add a series of "test" rules before to override elements, to prevent issues due to array shift (insert of new plugins). If test fail, the client should send a message to notify the problem.

This issue is somehow related to #3117 because a general cleanup is useful to define better what to override.

• Revert Update localConfig.json #3687 when this issue has been solved.

[tdipisa]

@offtherailz, @mbarto please, can you provide an estimate for this issue? I think that could be the case to define a MS data directory since it can be useful also for other custom resources (custom annotation SVG symbols, geostory default images etc.) that can be externalized without impacting on the MS deploy.

[MV88]

@ElenaGallo this is non testable in QA