expo-iap: auto-detect VegaOS builds instead of requiring isVegaEnabled?

[hyochan]

The Expo plugin rewrites the app for VegaOS builds when isVegaEnabled is set in the plugin options.

Question: should the plugin auto-detect a VegaOS build (e.g. Vega markers in the project or an explicit store target for the build invocation) instead of requiring the flag, with the flag kept as an explicit override?

Context: Vega and FireOS ship as different install artifacts, and the build-time store resolver only names play, horizon, and amazon — Vega is detected at runtime through the platform instead. The check runs at prebuild before any InstallReferrer/API signal exists, so the build intent — not the device — has to carry the answer.

If auto-detect sounds right, what markers should count: an environment variable set by the Vega build invocation, explicit config objects for FireOS vs Vega, or something else?

Note: this only concerns expo-iap. react-native-iap has no build flag — it resolves the store at runtime, so it is unaffected by this question.

[selmancanklnc]

@hyochan I'd keep an explicit signal, but move it from a project marker to the build invocation, and I'd avoid auto-detecting from files in the project.

Why not project markers

If Vega and FireOS ship as different artifacts, they are usually built from the same project. Any Vega marker in the repo is then present in the FireOS build too, so marker-based detection would rewrite the FireOS build as well. The only thing that differs between the two builds is how the build was invoked, which matches your point that the build intent has to carry the answer.

What I'd suggest

1. An environment variable read at prebuild, for example EXPO_IAP_STORE=vega. Config plugins run in Node during prebuild, so the plugin can read process.env directly. With EAS it is one line per build profile:

{
  "build": {
    "firetv": { "env": { "EXPO_IAP_STORE": "amazon" } },
    "vega":   { "env": { "EXPO_IAP_STORE": "vega" } }
  }
}

2. A clear precedence order: explicit plugin option > environment variable > current default. People who set isVegaEnabled today keep the same behaviour, and CI setups get a per-build switch without editing app.json.

3. A store value instead of a boolean. Since the build-time resolver already names play, horizon and amazon, a single option such as store: 'play' | 'horizon' | 'amazon' | 'vega' (and the same values in the env var) fits better than a Vega-only flag. It also avoids contradictory combinations later.

4. Warn instead of guessing. If the plugin sees Vega markers in the project but neither the option nor the env var is set, print a prebuild warning such as "Vega markers found; set EXPO_IAP_STORE=vega for the Vega build". That catches the forgotten-flag case without the risk of a silent wrong rewrite.

This keeps the build deterministic: the same command always produces the same artifact, whatever else is in the repository.

[hyochan]

Good idea, and we missed it. Fire OS already follows a connected Fire device on debug builds, but #482 marked its explicit declaration deprecated. Going forward Fire OS keeps both, and the declaration wins: modules.amazon.fireOS or EXPO_IAP_FIREOS=1 when set, the connected device otherwise. We'll follow up in #500.

We'll keep this to Fire OS rather than add a store option; Play and Horizon stay with the Gradle resolver. Vega already works this way in expo-iap 5.8.1 (#489): modules.amazon.vegaOS or EXPO_IAP_VEGA=1 decide, and a root manifest.toml only applies when neither is set. EXPO_IAP_VEGA only turns Vega on, so a root that builds both should set modules.amazon.vegaOS: false for the Fire build.

[selmancanklnc]

Thanks, that makes sense, and keeping it to Fire OS with the declaration winning is a clean rule.

One small follow-up on the last point. Because isEnvFlagEnabled only checks for '1', EXPO_IAP_VEGA=0 is treated as "not set", so a root with a manifest.toml still falls back to auto-detection for the Fire build. That means the Fire build has to change app.json (or use an app.config.js that reads the env) just to turn Vega off.

If '0' counted as an explicit false, one config could serve both builds with nothing but per-profile env in eas.json:

function readEnvFlag(name: string): boolean | undefined {
  const value = process.env[name];
  return value === '1' ? true : value === '0' ? false : undefined;
}

and then vegaProjectOptions?.enabled ?? readEnvFlag('EXPO_IAP_VEGA'), with the same helper for EXPO_IAP_FIREOS in #500. Unset keeps today's behaviour, so it is backwards compatible.

Happy to open a PR for it if that's useful.

[hyochan]

Update: rather than add values, #500 now deprecates the EXPO_IAP_* environment flags, since each is one more surface to maintain. For a root that builds both, keep one eas.json line per profile, ORG_GRADLE_PROJECT_openiapStore=amazon for Fire, and have app.config.js read it to set modules.amazon.fireOS for that build only; the Vega profile keeps detecting its manifest.toml. So no '0' PR is needed, but thanks for offering.

[selmancanklnc]

Makes sense, one Gradle property per profile plus app.config.js is simpler than a second set of env flags. Thanks for the quick follow-up in #500!

Since #500 settles this, feel free to mark the thread as answered so it shows as resolved.