Generating an apk from a signed aab locally with bundletool, that would also require having the keystore locally (and the bundletool), which would make you download the credentials from EAS first (in a team) before doing that, so that’s a bit of a far fetched scenario in my opinion.
- it’s harder to document because there is no one default value
- it’s not that obvious, maybe it would be better if default distribution was internal when buildType is apk
Those are valid points. Maybe you could leave your defaults in place, but add some kind of validation step, saying ‘internal distribution is not compatible with default buildType app-bundle’ or if you specify buildType, but not distribution, it should also warn you that buildType apk is incompatible with the default buildType (store). There’s many tools (including for example git) that warn you when you provide it with incompatible options, and the docs can stay simple with a single set of (compatible) defaults.
I really don’t think there are that many options that are actually this dependent on each other, so that would also be an argument for simple validation versus multiple sets of defaults.
In general, all I’m offering you is a fresh perspective. I’m going through this process as an experienced RN developer, that does a lot of build and deployment management (and automation), and who tries to apply EAS tooling to that process for the first time. So if I run into something that seems counter-intuitive to me, then I’m bringing it up for discussion.
I appreciate your feedback.