Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support dynamic configuration files #3141

Closed
imhoffd opened this issue Jun 23, 2020 · 4 comments · Fixed by #3756
Closed

Support dynamic configuration files #3141

imhoffd opened this issue Jun 23, 2020 · 4 comments · Fixed by #3756

Comments

@imhoffd
Copy link
Contributor

imhoffd commented Jun 23, 2020

Capacitor should allow a capacitor.config.{ts,js} file so that configuration can be generated based on environment.

Related: #1741, #1478

@buschtoens
Copy link
Contributor

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 .gitignored.

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.

@imhoffd
Copy link
Contributor Author

imhoffd commented Nov 3, 2020

@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.

@aparajita
Copy link

Whether or not dynamic renaming is supported, for obvious reasons js/ts is infinitely preferable as a config file format.

@ionitron-bot
Copy link

ionitron-bot bot commented Nov 11, 2022

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.

@ionitron-bot ionitron-bot bot locked and limited conversation to collaborators Nov 11, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants