module.exports = {
expo: {
name: "My App",
slug: "my-app",
extra: {
// În dev va lua din .env local, în EAS Build va lua din EAS Secrets
apiUrl: process.env.API_URL ?? "https://api.dev.com",
sentryDsn: process.env.SENTRY_DSN,
}
}
};Am trecut recent prin migrarea unui proiect destul de măricel pe Expo EAS — undeva la 15k useri activi pe lună. Una dintre cele mai mari bătăi de cap a fost gestionarea cheilor de API și a secretelor. Dacă vii din web, ai tendința să crezi că un simplu .env rezolvă totul, dar în React Native tot codul ajunge pe telefonul userului.
Dacă pui o cheie secretă în codul de frontend, ea poate fi extrasă în 5 minute cu un simplu tool de decompilare. De aceea, trebuie să facem o distincție clară între ce e secret de build (cum ar fi token-ul de Sentry sau cheile de semnare Google/Apple) și ce sunt variabile de configurare (URL-ul de API).
Capcana din .env.development și .env.production
La început, am folosit abordarea clasică: .env.development pentru local și .env.production pentru release. Le ignoram în .gitignore și gata. Dar când am trecut la build-uri automate cu EAS Build în cloud, am dat de zid.
EAS nu are acces la fișierele tale locale .env pentru că ele nu sunt trimise în repository-ul de git. Dacă le trimiți în git ca să meargă build-ul în cloud, ai compromis securitatea.
Merge bine pentru proiecte mici unde ești singurul dev, dar e extrem de nasol când lucrezi în echipă sau ai pipeline-uri de CI/CD.
Cum rezolvă EAS Secrets problema asta?
EAS Secrets sunt variabile criptate pe care le definești în dashboard-ul Expo sau prin CLI. Acestea sunt injectate ca variabile de mediu în mașina virtuală care rulează build-ul tău în cloud.
Dar atenție, e o mare capcană aici: EAS Secrets sunt disponibile doar în timpul build-ului. Ele nu ajung automat în codul tău de runtime (JS) decât dacă le maprezi explicit în app.config.js.
Setup-ul meu care funcționează perfect
După ce am pierdut vreo 4 ore cu build-uri eșuate, am ajuns la o structură curată pe care o folosesc acum la toate proiectele:
- Variabile non-sensibile (ex:
API_URL): Le țin în.env.developmentlocal, iar pentru producție le pun în EAS Secrets. - Secrete de build (ex:
SENTRY_TOKEN): Le pun direct în EAS Secrets. Ele nu trebuie să ajungă niciodată în codul JS. - Configurarea din app.config.js: Folosesc un fișier de configurare dinamic care citește aceste variabile la build-time și le expune prin
expo-constants.
Trade-off-ul sincer? Cu metoda asta, e destul de enervant să testezi build-ul de producție local (npx expo start --no-dev). Trebuie să ai toate variabilele de producție definite local într-un fișier .env temporar sau să le injectezi manual în terminal. Dar e un preț mic de plătit pentru a avea build-uri sigure în cloud.
Voi cum gestionați diferențierea asta între dev și prod în Expo? Mergeți pe varianta cu EAS Secrets sau preferați să generați fișierele de configurare la build-time în pipeline-ul propriu?