Prácticas recomendadas de Expo Platform

Un resumen condensado de las 25 prácticas recomendadas más importantes extraídas de cada página en esta sección.

1. Fija el SDK en el momento del andamiaje: Usa npx create-expo-app@latest --template default@sdk-57 (o equivalente) para que expo comience en ~57.0.4 - actualizar más tarde es más difícil que comenzar en el SDK soportado actual.

2. Ejecuta expo-doctor después de cada andamiaje o actualización: npx expo-doctor detecta versiones de módulos nativos desajustadas, campos app.json inválidos y desvío de configuración antes de que fusiones una rama de actualización.

3. Siempre usa npx expo install para paquetes Expo: npm install manual puede extraer stubs de JS que no coincidan con los binarios nativos para el SDK 57 - el éxito de compilación no garantiza estabilidad en tiempo de ejecución.

4. Trata app.config.ts como la fuente de verdad: La configuración dinámica admite entornos, ayudantes tipados y plugins condicionales; app.json estático solo no escala más allá de un sabor de compilación.

5. Nunca confirmes secretos en extra o EXPO_PUBLIC_*: Prefija variables públicas con EXPO_PUBLIC_ solo para valores seguros para enviar en el bundle del cliente; los secretos del servidor pertenecen en EAS Secrets.

6. Audita el manifiesto público antes de la liberación: Ejecuta npx expo config --type public y confirma que no hay claves privadas, URLs internas o endpoints de staging filtradas en la configuración de tiempo de compilación.

7. Lee la configuración en tiempo de ejecución a través de Constants.expoConfig: No importes app.json en código de característica - el manifiesto procesado desde el pipeline de complemento de configuración de Expo es lo que realmente se envía.

8. Comienza con Expo Go, avanza a compilaciones de desarrollo: Expo Go es excelente para aprender y demos; agrega expo-dev-client tan pronto como dependas de módulos nativos no incluidos en Expo Go.

9. Reconstruye el cliente de desarrollo después de cada actualización del SDK: Las actualizaciones OTA (eas update) cambian solo JavaScript - los shells nativos de expo-dev-client deben reconstruirse con eas build --profile development.

10. Registra la raíz con registerRootComponent: Los puntos de entrada bare o brownfield que omiten bootstrap de expo pierden la inicialización de autolinking y fallan misteriosamente cuando llaman a módulos nativos.

11. Prefiere requireNativeModule de expo en apps: Los paquetes de biblioteca deben importar desde expo-modules-core para evitar ciclos de dependencia de pares; el código de app puede usar la re-exportación de expo.

12. Asigna perfiles de compilación de EAS a entornos: Usa claves environment de eas.json (development, preview, production) para que credenciales y variables env se resuelvan consistentemente en CI y localmente.

13. Extrae variables env con eas env:pull: Sincroniza secretos gestionados por el equipo en .env.local para desarrollo local sin copiar valores en chat o unidades compartidas.

14. Actualiza SDKs secuencialmente: Saltar múltiples versiones de SDK en una PR compone cambios disruptivos - avanza de 54 - 55 - 56 - 57, leyendo cada changelog entre fusiones.

15. Elimina carpetas nativas obsoletas después de actualizaciones de CNG: ios/ y android/ confirmados de un SDK más antiguo bloquean plantillas prebuild para RN 0.86 - ignóralos con gitignore y deja que EAS Build regenere.

16. Expresa cambios nativos como complementos de configuración: Editar a mano archivos Info.plist o AndroidManifest.xml generados se pierden en npx expo prebuild --clean (el default del SDK 57).

17. Escribe complementos de configuración idempotentes: Los complementos que agregan reemplazos regex dos veces corrompen proyectos nativos - diseña complementos para ser seguros en ejecuciones de prebuild repetidas.

18. Establece owner para proyectos de organización: Omitir "owner": "org-slug" en app.config enruta compilaciones y credenciales a una cuenta personal en lugar del equipo.

19. Un projectId por binario de app: Reutilizar un proyecto de EAS en IDs de bundle no relacionados colisiona credenciales, canales de actualización y variables de entorno.

20. Los ingenieros predeterminados tienen rol Developer: Reserva Owner para cobertura del bus-factor (máximo dos owners); Admin para líderes que administran facturación e invitaciones - no cada IC.

21. Usa tokens de robot para CI, no contraseñas personales: Los usuarios de robot con alcance de organización sobreviven a las salidas de empleados y proporcionan una ruta de revocación auditable.

22. Mantén slug flexible, projectId estable: Renombra slugs de visualización cuando la marca cambia; nunca rotes projectId - Los servicios de EAS se basan en el UUID para la vida útil de la app.

23. Coincide MainComponent / moduleName con el registro de JS: Las apps bare cuya entrada nativa dice "MyApp" mientras JS registra "main" muestra una pantalla en blanco sin error de JS obvio.

24. Libera SharedObjects explícitamente: Los manejadores nativos de larga vida desde módulos Expo (reproductores, sensores) filtran memoria hasta que release() o el hook del paquete limpia al desmontar.

25. Lee las notas de la versión de SDK 57 y RN 0.86 antes de actualizar: Hermes, Reanimated y los defaults de New Architecture cambian el comportamiento incluso cuando TypeScript aún se compila - trata el changelog como parte de la lista de verificación de actualización.

Preguntas frecuentes

Relacionado

• Conceptos básicos de Expo Platform - tour de una página de primitivos de flujo de trabajo de Expo
• Guía rápida de create-expo-app - andamio con la plantilla de SDK correcta
• app.json & app.config.js - configuración dinámica y patrones seguros para secretos
• Expo Go vs Compilaciones de desarrollo - cuándo dejar Expo Go
• Actualizando versiones del SDK de Expo - instalar --fix, doctor y regeneración nativa
• Cuenta de Expo, Proyectos y Permisos - RBAC de org y tokens de CI

Versiones de pila: Esta página fue escrita para React 19.2.3, React Native 0.86.0, y Expo SDK 57 (expo ~57.0.4).