import { ExpoConfig, ConfigContext } from 'expo/config';
export default ({ config }: ConfigContext): ExpoConfig => {
const IS_DEV = process.env.APP_ENV === 'development';
const IS_STAGING = process.env.APP_ENV === 'staging';
return {
...config,
name: IS_DEV ? 'App (Dev)' : IS_STAGING ? 'App (Staging)' : 'App Native',
slug: 'my-native-app',
extra: {
// Variabile preluate din EAS Secrets la build-time
apiUrl: process.env.API_URL ?? 'https://api.default.com',
sentryDsn: process.env.SENTRY_DSN,
eas: {
projectId: 'your-project-id-here'
}
}
};
};Am văzut de prea multe ori chei de API expuse public sau build-uri eșuate pe EAS pentru că cineva a uitat un fișier .env local. În React Native cu Expo, gestionarea variabilelor de mediu e un pic mai perfidă decât la un backend clasic de Node.js, pentru că tot ce ajunge pe telefon poate fi decompilat.
După ce am configurat pipelines de build pentru peste 10 aplicații de Expo în ultimii trei ani, mi-am stabilit un workflow clar de care nu mă mai abat. Hai să vedem cum separăm mediile fără să ne prindem urechile.
Marea greșeală: EXPO_PUBLIC_ și secretizarea falsă
De la Expo SDK 49 încoace, avem suport nativ pentru fișiere .env. Regula de aur pe care unii încă o ratează: tot ce începe cu EXPO_PUBLIC_ va fi încorporat direct în bundle-ul JavaScript compiled.
Dacă pui EXPO_PUBLIC_STRIPE_SECRET_KEY=sk_live_123 în .env.production, acea cheie este 100% publică. Am analizat la un moment dat APK-ul unui client cu 12k useri și am extras cheia de SendGrid în mai puțin de două minute folosind un simplu string extractor.
Variabilele EXPO_PUBLIC_ sunt doar pentru resurse necritice: URL-ul de API, Sentry DSN, public API keys (Google Maps, Stripe Publishable Key). Cheile cu adevărat secrete nu au ce căuta niciodată pe client. Punct.
Workflow local: .env.development vs .env.production
Pentru dezvoltare locală, structura mea standard arată așa:
.env.development(comitat în git sau salvat ca.env.example) – conține endpoint-uri de local/staging..env.local(trecut obligatoriu în.gitignore) – override-uri personale pentru mașina de dev.
Expo CLI citește automat aceste fișiere în funcție de modul în care rulezi npx expo start. Dar când trecem la build-uri reale prin EAS (Expo Application Services), lucrurile se schimbă.
EAS Secrets: Cum trimiți date confidențiale în CI/CD
Nu comiți NICIODATĂ .env.production în repository. Atunci cum le primește EAS Build când rulează în cloud?
Aici intervin EAS Secrets. Acestea sunt variabile stocate criptat în infrastructura Expo, injectate la build-time în containerul unde se compilează aplicația.
Le setezi extrem de simplu din terminal:
eas secret:create --scope project --name API_URL --value https://api.domeniu.ro
EAS le injectează în process.env în timpul build-ului. Le poți accesa apoi în app.config.ts pentru a genera dinamic fișierul de configurare al aplicației.
Trade-off-uri și minusuri reale
EAS Secrets funcționează excelent pentru CI/CD, dar au și părți enervante:
- Debugging dificil: În dashboard-ul Expo vezi doar numele variabilei, nu și valoarea. Dacă ai greșit un caracter într-o cheie lungă, nu o poți edita — trebuie să o ștergi și să o creezi din nou.
- Propagare locală: Când rulezi
eas build --local, EAS Secrets din cloud nu se descarcă automat pe mașina ta. Trebuie să le ai configurat local într-un.envsau transmise explicit.
Configurarea dinamică în app.config.ts
Cea mai curată abordare este să folosești un app.config.ts care citește process.env și adaptează configurația în funcție de profilul definit în eas.json (development, staging, production).
Voi cum gestionați secret-urile când aveți build-uri paralele de Staging și Prod? Le treceți prin eas.json sub blocul env sau folosiți exclusiv EAS Secrets din CLI?