[BUG] Deployment configs do not always recompile when they should

[jfmcquade]

Describe the bug

Making changes to a deployment config should cause the config to recompile when setting the active deployment. Whilst this works as expected when editing the deployment's config.ts file directly, sometimes changes made to other files have effects on the config and should also therefore trigger a recompile. There are two main cases where changes made to other files do not trigger the deployment config to recompile as it should, which can cause knock-on issues:

• [ ] 1. Changes made to a deployment's parent deployment config (first identified in #1809)

The following bugs are addressed by #1885, whereby a dev can manually bump the DEPLOYMENT_CONFIG_VERSION number (this feature was already available but less prominent)

• [x] 2.1. Changes made to packages/data-models/deployment.model.ts, which should affect all deployment configs
• [x] 2.2. Changes made to packages/data-models/appConfig.ts, which should affect all deployment configs, as above

To Reproduce

1.

1. Choose a pair of deployments that are parent and child, e.g. plh and plh_global.
2. Run yarn workflow deployment set plh_global to ensure the child's config is compiled
3. Make a change to one of the values assigned in the parent deployment's config file, e.g. in .idems_app/deployments/plh/config.ts, change config.app_config.APP_LANGUAGES.default = "gb_en" to config.app_config.APP_LANGUAGES.default = "test"
4. Run yarn workflow deployment set plh_global. This will trigger the plh config to recompile, but these changes will not be reflected in the compiled child's config. You can see this by inspecting .idems_app/deployments/plh_global/config.json

This bug is now resolved by #1885:

2.

After #1873 was merged (which adds a supabase: {} property to the top level of deployment configs), the bug can be observed when switching to a deployment that already has a compiled config.json file:

1. Checkout master
2. Choose a deployment with a compiled contents.json file, and check out that deployment. E.g. if the file .idems_app/deployments/plh_global/config.json exists, then you can run yarn workflow deployment set plh_global
3. Inspect the file .idems_app/deployments/activeDeployment.json and note that there is no entry for "supabase". If you start the app with yarn start, the following error will be logged in the console:

Workaround

There is a general workaround for this issue, which involves manually forcing the deployment config to recompile. One way to do this is to delete the relevant config.json file, e.g. .idems_app/deployments/plh_global/config.json, and then run yarn workflow deployment set.

[chrismclarke]

One of the issues noticed, is that because the isConfigUpToDate() check that happens in packages\scripts\src\commands\deployment\utils.ts uses file timestamps to verify if up-to-date (comparing config.ts with compiled config.json), any updates to files referenced from within the config.ts won't be taken into account.

E.g. if a deployment imports data from a child skins folder or loads encryptedConfig, then changes within those imported files won't prompt recompile.

As a short term/initial solution it might be worth just changing the default behaviour so that when if you run yarn workflow deployment set [deployment_name] whilst the active deployment is already [deployment_name] then it forces recompilation. Alternatively a flag could be added like --force, to force recompilation.