Generate env files from EJSON with local overrides

[kieran-osgood-shopify]

Stack Context

This PR is two phased with #582 to achieve: Local and E2E runs will now always run the same configs - no drift.

#580 generate .env from .ejson
#582 generate e2e/.env from ejson, use the e2e/.env in Bitrise, meaning we can delete all the secrets in the bitrise UI as they're sourced from ejson now, and developers can have the exact config of bitrise locally

Why?

Relying on sharing 1password files around was slow and prone to drift
We had no solution for running the same config as CI locally
The encrypted files provide one reviewable source for shared configuration
.env.local keeps personal overrides persistent across dev up runs.

The generator remains separate from setup_storefront_env, so public contributors do not need EJSON access and their hand-written .env remains untouched.

What?

• .env and e2e/.env are now generated from committed encrypted EJSON files during dev up
• Make scripts/setup_storefront_env read-only toward .env.
• Apply .env.local as an override on top of the .env (last key wins)
• ** Preserves existing .env by migrating it to .env.local**

For outside contributors the workflow remains the same, copy .env.example to .env, fill it in, and run the samples

Also noticed there was some --skip-optional-prompts that are stale/were removed recently so did some clean up

How to test

run: dev up

You should now see the following changes:
your existing .env will be copied to .env.local
.env has been generated from the stored config/secrets/demo.ejson
e2e/.env generated from config/secrets/e2e.ejson

Compare the .env and .env.local - consider whether you need the .local overrides and remove unnecessary overrides to receive same config as the rest of the team

[kieran-osgood-shopify]

• Generate env files from EJSON with local overrides #580 : 2 dependent PRs (#581 , #582 ) 👈 (View in Graphite)
• Promote checkout-guest to run on Swift/Kotlin #561 : 2 other dependent PRs (#562 , #599 )
• Promote cart-hardcoded-buyer-identity test to run on swift/kotlin #560
• feat(e2e): add the present-and-close checkout test on all four targets #559
• Add local maestro runner - Run cart control-link on kotlin/swift #558
• Replace the E2E suite cross product with Maestro tags in CI #557
• feat(e2e): select tests by Maestro tag instead of scenario flags #556
• feat(e2e): add an E2EController to each sample app #555
• Add the E2E control link parser to all four sample apps #554
• Add sample app test seams and run them in CI #553
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[github-actions]

React Native — Coverage Report

Lines	Statements	Branches	Functions
	90.97% (363/399)	87.29% (213/244)	100% (92/92)

[kieran-osgood-shopify]

This sets the domain for sample app to shared staff store instead of the e2e test store

[bitrise]

Install this build

Open Tophat, select your target device, then click Install. Links open on the Mac running Tophat.

SDK	Install
React Native	Install with Tophat
Swift	Install with Tophat
Kotlin	Install with Tophat

Checkout Kit E2E results

Status	Suite	Target	Platform	OS version tag	Device
✅	react-native-ios	react-native	ios	latest	iPhone 15 iOS 27 Beta
✅	react-native-android	react-native	android	latest	Google Pixel 9 Android 17.0
✅	kotlin-android	kotlin	android	latest	Google Pixel 9 Android 17.0
✅	swift-ios	swift	ios	latest	iPhone 15 iOS 27 Beta

[kyle-schellen]

We don't mean physically delete the file here do we?

If we delete the file and we want to update to the shared config, we could find ourselves in an odd scenario where we have the shared config in .env but the samples are using a stale config.

This helped me visualize:

before
.env         token A
.env.local   token A
sample files token A

delete .env.local

team updates shared token to B
run dev up

migration copies old .env token A into new .env.local
generator updates .env to token B
sample setup prefers .env.local token A

after
.env         token B
.env.local   token A
sample files token A <--- stale

Maybe this might be more clear:
“Remove entries from .env.local, but keep file, to fall back to shared config.”

[kieran-osgood-shopify]

Great catch - I naively implemented it as "if you dont have a .env.local yet we'll just copy your .env over there"

I later forgot about that with this delete guidance

I think the correct fix here is to instead check for a marker in the .env to indicate whether its generated or not

e.g. I can check that this string " # Generated by scripts/generate_env_files from config/secrets/demo.ejson." is present in the file as that is setup in each generation

[kyle-schellen]

I could be missing something but say I previously configured a Customer Account client ID, so generated sample config contains A. Then I clear CUSTOMER_ACCOUNT_API_CLIENT_ID in .env.local and rerun dev up because I want it gone. Since this only accepts a non-empty root value, won’t it fall back to A from generated config and write A back out again? Seems like I can no longer clear it. Same for shop ID. Or is there a work-around for this scenario.