module.exports = {
expo: {
name: "My App",
slug: "my-app",
version: "1.0.0",
extra: {
apiUrl: process.env.EXPO_PUBLIC_API_URL || "https://dev.api.com",
sentryDsn: process.env.SENTRY_DSN, // Nu are EXPO_PUBLIC_, deci e accesibil doar la build-time
},
},
};Salutare. Săptămâna trecută am ajutat o echipă să curețe un repo de React Native după ce un junior a împins cheia privată de Stripe direct pe GitHub. Clasic, se întâmplă și la case mai mari. Hai să vedem cum gestionăm corect secretele în Expo, de la local development până la build-ul în cloud cu EAS (Expo Application Services), fără să ne spargem capul.
Capcana locală: .env.development vs .env.production
În local, totul e simplu. Începând cu SDK 49, Expo are suport nativ pentru fișiere .env prin Metro. Pui un EXPO_PUBLIC_API_URL=https://dev.api.com în .env.development și totul merge uns.
Problema apare când facem pasul spre producție. Mulți developeri își imaginează că dacă adaugă .env.production în .gitignore și îl au local pe mașină, EAS Build o să-l citească miraculos când rulează build-ul.
Este complet greșit. Mașina de build de la EAS rulează într-un mediu complet izolat în cloud (pe serverele lor de macOS sau Linux). Deoarece .env.production este în .gitignore, el nu ajunge niciodată pe serverul lor. Rezultatul? Build-ul se va genera cu variabile undefined și te vei trezi cu ecrane albe în producție.
EAS Secrets: Unde trăiesc cheile de producție
Soluția oficială și sigură pentru mediul de producție sunt EAS Secrets. Acestea sunt variabile de mediu stocate criptat în dashboard-ul Expo. Le poți crea foarte ușor din terminal:
eas secret:create --scope project --name EXPO_PUBLIC_API_URL --type string --value https://api.productie.com
Când EAS pornește build-ul, el injectează automat aceste secrete în containerul de build.
Trade-off-ul sincer: E o metodă super sigură, dar debug-ul e un chin absolut. Dacă ai greșit un singur caracter într-o cheie din consola EAS, afli abia după 15 minute (cât durează build-ul) sau, mai rău, când pornește aplicația în producție și crapă la primul request. Am pierdut odată peste 3 ore la un proiect cu 10k useri activi doar pentru că am pus din greșeală un spațiu (whitespace) la finalul unei chei în dashboard-ul Expo.
Cum legăm totul curat în app.config.js
Deși prefixul EXPO_PUBLIC_ injectează automat variabilele în codul tău JS, personal prefer o abordare mai explicită și mai robustă folosind app.config.js.
Această metodă îți permite să validezi existența cheilor înainte de a porni build-ul și să separi clar configurațiile în funcție de build profile (development, preview, production). Vezi exemplul de cod de mai jos pentru a înțelege cum mapăm variabilele din proces în proprietatea extra.
Sfaturi practice pentru a nu pierde nopțile
- Folosește build-uri locale pentru teste rapid: Înainte de a trimite build-ul în cloud (unde minutele costă după ce depășești limita gratuită), rulează
eas build --local --profile preview. Așa verifici rapid dacă variabilele tale de mediu sunt injectate corect în build-ul local. - Nu pune secrete grele în codul de client: Orice variabilă prefixată cu
EXPO_PUBLIC_va fi vizibilă la o simplă decompilare a APK-ului/IPA-ului. Cheile private (cum ar fi cheia secretă Stripe sau parole de baze de date) nu au ce căunta în aplicația de mobil. Ele trebuie să stea doar pe backend.
Voi cum gestionați secretele în proiectele voastre mari de Expo? Mergeți pe varianta simplă cu EXPO_PUBLIC_ peste tot sau preferați o validare mai strictă cu scheme de tip Zod în app.config.js?