module.exports = {
expo: {
name: "My App",
slug: "my-app",
extra: {
apiUrl: process.env.API_URL || "https://api.staging.com",
stripeKey: process.env.STRIPE_PUBLISHABLE_KEY,
}
}
};Am văzut prea des oameni care își urcă din greșeală cheile de API în repo-ul de Git sau se încurcă în .env când trec de la staging la producție în Expo. Chestia asta te poate costa scump, mai ales dacă te trezești cu facturi uriașe pe Firebase sau Stripe din cauza unui token expus. Hai să vorbim direct despre cum facem managementul de secrete în Expo, fără să ne complicăm viața.
La un proiect recent, o aplicație cu peste 15.000 de utilizatori activi, am pățit-o: o cheie de Stripe de producție a fost suprascrisă la un build de staging din cauza unui .env gestionat prost pe CI. Am pierdut o zi întreagă să facem cleanup și să rotim cheile. De atunci, am adoptat o regulă clară.
Mitul lui .env în React Native
În web e simplu: pui .env pe server și gata, codul rulează în backend, în siguranță. În React Native, tot ce pui în codul de frontend ajunge, mai devreme sau mai târziu, în binarul aplicației (APK sau IPA). Oricine are puțină ambiție poate decompila un APK în 5 minute ca să-ți extragă cheia de Google Maps sau Stripe.
Deci, primul trade-off major pe care trebuie să-l înțelegi: secretele din aplicația mobilă nu sunt cu adevărat secrete. Tot ce ajunge în JS-ul bundle-uit poate fi citit. Totuși, avem nevoie de variabile diferite pentru development și producție (cum ar fi URL-ul de API). Aici intervin .env.development și .env.production.
Soluția curată: app.config.js în loc de app.json
În loc să folosești librării greoaie de react-native-dotenv care adesea crapă la cache-ul de Babel, prefer să folosesc un fișier app.config.js dinamic. Acesta citește variabilele din proces (adică din terminal sau din serverul de CI) și le injectează în aplicație prin obiectul extra.
Am economisit cam 20% din timpul de debug pe proiectele noastre doar prin eliminarea cache-ului buclucaș de Babel care ținea minte vechile variabile din .env atunci când schimbam branch-ul.
Cum intră EAS Secrets în ecuație
Când rulezi eas build în cloud-ul lor, mașinile virtuale de la Expo nu au acces la fișierele tale locale .env (pe care sper că le ai în .gitignore). Aici intervin EAS Secrets. Le definești în dashboard-ul Expo sau direct prin CLI:
eas secret:create --scope project --name API_URL --value https://api.production.com
EAS le injectează automat ca variabile de mediu (process.env.API_URL) în timpul build-ului.
Trade-off-ul sincer: EAS Secrets sunt excelente pentru build-urile din cloud, dar devin enervante dacă vrei să rulezi build-ul local (eas build --local). Pentru build-urile locale, trebuie să ai un script care descarcă aceste secrete sau să le configurezi manual în mașina ta de build.
Cum le legăm pe toate în eas.json
Configurația ideală folosește eas.json pentru a defini profilele (development, preview, production) și app.config.js pentru a mapa variabilele corecte.
În eas.json, poți adăuga un nod de env pentru fiecare profil. De exemplu, pentru profilul de production, te asiguri că ai doar cheile care fac legătura cu secretele din EAS. În felul acesta, nu mai ai nevoie de fișiere .env fizice în producție, ci le folosești doar local pentru development rapid.
Voi cum gestionați secretele când lucrați în echipe mari pe Expo? Rămâneți pe abordarea clasică cu fișiere .env sau lăsați totul în seama EAS Secrets?