module.exports = {
expo: {
name: "MyAwesomeApp",
slug: "my-awesome-app",
version: "1.0.0",
extra: {
// Fallback local dacă EAS Secret nu este definit la build
apiUrl: process.env.EXPO_PUBLIC_API_URL || "https://api.staging.mysite.com",
sentryDsn: process.env.SENTRY_DSN || null
}
}
};Salutare! Dacă ai lucrat cu Expo în ultima vreme, sigur te-ai lovit de problema asta: cum pui cheile de API ca să nu le urci pe GitHub, dar să fie accesibile și pe emulatorul local, și în build-ul de producție din EAS.
Am pățit-o acum un an la un proiect cu vreo 12k utilizatori activi. Am realizat la un release că trimisesem cheia de Stripe de test în build-ul de producție din greșeală. Am pierdut vreo 3 ore să-mi dau seama unde s-a produs scurtcircuitul între .env.development și ce citea EAS-ul în cloud.
Marea confuzie: .env în React Native
Trebuie să înțelegem un lucru extrem de simplu, dar pe care mulți juniori îl ignoră: în React Native nu există "runtime environment" securizat, așa cum ai în Node.js pe backend. Tot ce pui în bundle-ul de Javascript poate fi citit de oricine face un decompile simplu pe APK sau IPA.
Deci, regula de aur: nu pune niciodată chei secrete de backend (cum ar fi cheia privată de la Stripe sau AWS Secret Access Key) în codul de mobil. Folosește variabilele de mediu doar pentru chei publice sau endpoint-uri de API (cum ar fi Sentry DSN sau URL-ul de staging/producție).
Cum împarți apele: .env.development vs .env.production
De la versiunea 49 încoace, Expo suportă nativ fișierele .env prin prefixul EXPO_PUBLIC_. E destul de comod.
Pentru rularea locală, e simplu: creezi un fișier .env.development și unul .env.production. Când rulezi npx expo start, Expo va citi automat din .env.development sau .env local.
Trade-off-ul sincer? Soluția asta e super utilă local, dar devine un calvar în CI/CD sau când folosești EAS Build. De ce? Pentru că fișierele tale .env sunt (și trebuie să rămână) în .gitignore. Când trimiți build-ul în cloud-ul celor de la Expo cu eas build, serverele lor nu au de unde să știe ce valori aveai tu în .env.production.
Salvarea vine de la EAS Secrets
Aici intervin EAS Secrets. Acestea sunt variabile de mediu criptate pe care le definești direct în dashboard-ul Expo Application Services sau prin CLI.
Când rulezi eas build, mașina virtuală din cloud preia aceste secrete și le injectează în procesul de build.
Pentru a le mapa corect, eu folosesc o abordare hibridă în app.config.js. În loc să mă bazez doar pe injectarea automată din EXPO_PUBLIC_, prefer să citesc variabilele explicit și să le expun prin obiectul extra. Astfel, am control total și pot pune valori de fallback dacă o variabilă lipsește din greșeală la build.
Partea bună la EAS Secrets? Sunt sigure, nu ajung pe GitHub și le poți asocia pe diferite platforme sau profile de build (development, preview, production).
Partea mai puțin bună? Dacă ai multe variabile, e destul de plictisitor să le adaugi manual în interfața Expo pentru fiecare mediu în parte. Eu am ajuns să folosesc un script de bash care citește .env.production și le împinge automat în EAS prin eas secret:create.
Voi cum gestionați treaba asta? Mergeți pe varianta simplă cu prefixul EXPO_PUBLIC_ direct în EAS sau folosiți app.config.js ca să aveți fallback-uri sigure?