module.exports = ({ config }) => {
const IS_DEV = process.env.APP_ENV === 'development';
return {
...config,
name: IS_DEV ? 'App (Dev)' : 'App Producție',
slug: 'my-app',
extra: {
apiUrl: process.env.EXPO_PUBLIC_API_URL || 'https://dev.api.example.com',
stripePublicKey: process.env.EXPO_PUBLIC_STRIPE_KEY,
eas: {
projectId: '12345678-abcd-1234-abcd-123456789abc'
}
}
};
};Acum vreun an, un junior din echipă a urcat din greșeală o cheie privată de Stripe direct în repozitoriu pentru că a confundat variabilele de mediu din Expo cu cele de backend. Am prins-o înainte să ajungă în producție, dar ne-a costat vreo două ore de panică și revocat chei. În postarea asta vă arăt cum facem noi management de secrets pe o aplicație cu peste 20k utilizatori activi, combinând EAS Secrets cu fișiere .env fără bătai de cap.
Regula de aur: JS Bundle-ul nu e un seif
Prima chestie pe care trebuie să o înțelegi la React Native și Expo este că tot ce ajunge în bundle-ul de JavaScript poate fi extras prin reverse engineering în mai puțin de 5 minute. Un simplu strings index.android.bundle scate tot la iveală.
Dacă pui un secret de backend în .env și îl imporți în aplicație, cheia aia devine publică. În client pui doar chei publice: URL-uri de API, chei de anon/publishable Supabase sau Stripe. De la SDK 49 încoace, Expo folosește prefixul EXPO_PUBLIC_ automat, exact ca Next.js. Dacă o variabilă nu are prefixul ăsta, Expo refuză să o expună în codul de client, ceea ce a eliminat jumătate din greșelile pe care le vedeam în trecut.
Medii diferite: .env.development vs .env.production
Pentru dezvoltare locală, structura mea preferată evită plugin-urile vechi de Babel. Păstrăm fișierele separate:
.env.development- pentru rulat local cunpx expo start.env.production- pentru teste locale de build
Toate fișierele .env* stau obligatoriu în .gitignore, în afară de un .env.example care conține doar cheile fără valori. Trecerea de la app.json la app.config.js ne permite să citim variabilele dinamic și să le injectăm în obiectul extra din configurare.
EAS Secrets: Piesa lipsă din CI/CD
Când generezi build-uri în cloud cu EAS (eas build --profile production), nu vrei să pui .env.production pe Git. Aici intervin EAS Secrets.
Le creezi direct din terminal:
eas secret:create --scope project --name EXPO_PUBLIC_API_URL --value https://api.domeniu.ro
EAS le injectează automat în containerul de build la nivel de sistem.
Trade-off-ul sincer: EAS Secrets sunt excelente pentru securitate în CI/CD, dar devin greu de urmărit dacă ai peste 20-30 de variabile și 3 medii diferite (dev, staging, prod). Nu există o interfață vizuală grozavă în dashboard unde să compari mediile side-by-side. De asta, recomand să folosești EAS Secrets strict pentru chei critice de build și certificate, iar restul să fie structurate clar în profiles din eas.json.
Cum arată setup-ul în app.config.js
În loc să folosești lib-uri terțe, te bazezi pe suportul nativ Expo și process.env. Codul de mai jos arată cum parsăm dinamic variabilele în funcție de profilul de build lansat.
Tu cum gestionezi enviroment-urile când ai mai mult de două medii (dev, staging, preview, prod) în Expo? Ai pățit vreodată să-ți scape chei în bundle?