What?
Currently deployments need to define config in typescript files which are used both during compile and at runtime (depending on operations). There is also an extendConfig utility function that can be used to merge configurations of parent-child deployments, although this can sometimes feel somewhat abstract and confusing, and deployments may also share content by pointing at the same google sheet ids.
Ideally it would be good to reduce the amount that these config files have to be authored directly, in favour of defining config in sheets (where possible) and removing the extendConfig util. Likely this should be split into 2 new flow_types, app_config which defines runtime config (currently specified via config.app_config) and core_config which defines compiler parameters.
At the same time it may be a good opportunity to refactor config files so that they do not need to be compiled with typescript, and type-checking against the statically generated json (possibly reviving/replacing #2086)
How?
Add flowtype, demo and test files for app_config flow_type
Add parser to compile app_config flows and generate deployment config output
Add QC checks to allow type-checking against app_config sheets and config inheritance feedback (ensuring order of priority as expected)
Add migration script to automatically upgrade config to new format when loading deployment
Follow-up PR for core_config flow_type.
Other details
We will still need to keep a minimal hardcoded config file that can be used to minimally store google sheet ids or git repo to populate initial content from, and likely handling encrypted config.
Given the potential for multiple sets of sheets defining overriding config properties it would be good to provide some sort of user feedback to make it clear where values originate from (e.g. name of sheets)
We may also want to think about providing utility functions that can be used with config, such as array_push to add an item to the end of an array and replace to manage string replacement
What? Currently deployments need to define config in typescript files which are used both during compile and at runtime (depending on operations). There is also an
extendConfigutility function that can be used to merge configurations of parent-child deployments, although this can sometimes feel somewhat abstract and confusing, and deployments may also share content by pointing at the same google sheet ids.Ideally it would be good to reduce the amount that these config files have to be authored directly, in favour of defining config in sheets (where possible) and removing the extendConfig util. Likely this should be split into 2 new flow_types,
app_configwhich defines runtime config (currently specified viaconfig.app_config) andcore_configwhich defines compiler parameters.At the same time it may be a good opportunity to refactor config files so that they do not need to be compiled with typescript, and type-checking against the statically generated json (possibly reviving/replacing #2086)
How?
app_configflow_typeOther details We will still need to keep a minimal hardcoded config file that can be used to minimally store google sheet ids or git repo to populate initial content from, and likely handling encrypted config.
Given the potential for multiple sets of sheets defining overriding config properties it would be good to provide some sort of user feedback to make it clear where values originate from (e.g. name of sheets)
We may also want to think about providing utility functions that can be used with config, such as
array_pushto add an item to the end of an array andreplaceto manage string replacement