module.exports = {
expo: {
name: "My App",
slug: "my-app",
version: "1.0.0",
extra: {
// Citește din EAS Secrets la build sau din .env local în dev
apiKey: process.env.API_KEY || "default-local-key",
apiUrl: process.env.API_URL || "https://api.dev.example.com",
},
},
};Am văzut prea des chei de Stripe sau Firebase adăugate direct în cod sau împinse din greșeală pe GitHub. În Expo, treaba asta devine și mai confuză când începi să folosești EAS (Expo Application Services) pentru build-uri în cloud. Am pățit-o și eu la un proiect cu vreo 12.000 de utilizatori activi, unde ne-am trezit că build-ul de producție folosea din greșeală baza de date de staging pentru că încurcasem variabilele locale cu cele din CI.
Problema de bază: Client-side vs Server-side
Înainte de orice, trebuie să înțelegem un adevăr crud despre aplicațiile mobile. Nu există „secrete” 100% sigure pe client. Tot ce pui în codul de React Native, chiar și într-un .env compilat, poate fi extras prin reverse engineering de cineva cu un pic de răbdare și un tool ca JADX.
Totuși, trebuie să diferențiem cheile de API (cum e o cheie publică de Stripe sau Firebase) de secretele reale (cum ar fi o cheie privată de AWS). Cele din urmă nu au ce căuta în aplicația mobilă; ele trebuie să stea în spatele unui API propriu. Pentru cheile de client-side însă, avem nevoie de o metodă curată de a le schimba între development și producție.
Cum împăcăm localul cu EAS Build
Când rulezi aplicația local, folosești probabil un fișier .env.development. Dar când trimiți build-ul în cloud-ul celor de la Expo (prin eas build), serverele lor habar n-au de fișierul tău local, pe care sper că l-ai pus deja în .gitignore.
Când dai eas build --profile production, serverul de build din cloud pornește o mașină virtuală curată. Ea nu are acces la fișierele tale locale. De aceea, trebuie să mergi în consola Expo (sau să folosești CLI-ul) și să adaugi secretele acolo. La build, EAS le injectează ca variabile de mediu normale (system env vars). Tot ce trebuie să faci tu este să le cureți în app.config.js și să le pui în obiectul extra pentru a le expune în aplicație.
Trade-off-ul de care nu-ți spune nimeni
Sistemul ăsta cu EAS Secrets merge excelent pentru pipeline-ul de CI/CD, dar are un dezavantaj enervant în daily workflow-ul unei echipe.
Dacă ai o echipă de 4-5 developeri, e destul de greu să ții sincronizate fișierele .env locale cu secretele adăugate în EAS. Schimbi o cheie în dashboard-ul Expo? Trebuie să le trimiți colegilor pe Slack noul string ca să-l pună în .env.local. Nu există un bridge nativ care să-ți tragă secretele din EAS direct în local pentru dev. Noi am rezolvat asta scriind un script mic de bash care descarcă secretele prin EAS CLI și generează fișierul .env local, dar e totuși un workaround pe care trebuie să-l menții singur.
Cum structurăm configurarea
În loc de clasicul app.json, recomand să folosești app.config.js. Acesta îți permite să rulezi cod JavaScript la momentul build-ului și să citești direct din process.env. Este cea mai curată metodă și nu depinde de plugin-uri de Babel care adesea dau crash din cauza cache-ului de Metro.
Voi cum gestionați treaba asta? Folosiți o soluție 3rd party pentru secrete locale sau vă bazați exclusiv pe infrastructura Expo?