Support dynamic configuration files
imhoffd opened this issue · 4 comments
FWIW we patched exactly this feature into our app project, because we needed separate configurations (e.g. server.url
, appId
) for different countries. We can now run cap sync
with some env variables which generates the capacitor.config.json
on-the-fly, right before copying it over into the native apps. The capacitor.config.json
files (generated source and the two copies in the native apps) are .gitignore
d.
This is working quite nicely so far and I'm much in favor of making capacitor.config.{ts,js}
official. But we found one major issue: whitelabeling / distinct apps per country.
When you update fields like appName
and appId
, these changes will not sync into the native apps when running cap sync
, because editProjectSettingsAndroid
and editProjectSettingsIOS
are only called once during cap add
.
Probably this would not be desirable anyway, as when you're running these types of multi-builds, you'll likely want to have a more sophisticated native build pipeline, with different product flavors on Android and build schemes on iOS.
I can't really speak for iOS, as I don't have a lot of experience with the platform, but at least on Android, you would likely prefer to run the full build matrix in one step instead of individually for performance & caching reasons. This however does not work with the current copy-one-config-at-a-time approach.
From my POV what we'd need ideally is being able to generate a whole set of configs, copy all of them over into the native projects (with different file names), and then have the native build pipeline select the right config for the right flavor. Alternatively the dependency could be inverted so that the native build pipeline calls cap
to generate a config on demand instead of cap sync
pushing it in.
The dependency inversion would have these additional neat side-effects:
- only required configs are generated, in case not the full build matrix is built
- the native build command is the definitive step that will determine the app flavors, so it likely has all necessary state to provide to the config generator
As neither of these proposed solutions (multi-config generation, dependency inversion) are implemented yet, we need to come up with a workaround. The generated config includes another build
key, that is read in the subsequent native Android & iOS build job. It looks like this:
{
"build": {
"environment": {
"APP_COUNTRY": "DE",
"APP_DEBUG": "true"
}
}
}
These variables are exported as environment variables and then used to determine what flavor / scheme to build.
@buschtoens We cannot dynamically rename Capacitor native projects at this time (I'm referring to reading appId
and calling those functions during sync)--see my comment here.
Whether or not dynamic renaming is supported, for obvious reasons js/ts is infinitely preferable as a config file format.
Thanks for the issue! This issue is being locked to prevent comments that are not relevant to the original issue. If this is still an issue with the latest version of Capacitor, please create a new issue and ensure the template is fully filled out.