Mejores Prácticas de Configuración del Proyecto

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

Scaffold con un pin de plantilla SDK: npx create-expo-app@latest --template default@sdk-57 - actualizar después cuesta más que empezar con el SDK soportado.
Ejecuta expo-doctor el primer día: Corrige el desfase de versiones antes del primer PR de características - doctor detecta desajustes de configuración y dependencias temprano.
Confirma archivos de bloqueo con la app: CI y EAS deben resolver el mismo árbol que el desarrollo local - las instalaciones flotantes ocultan el desfase nativo/JS hasta TestFlight.
Mantén los scripts de package.json aburridos: start, ios, android, lint, typecheck - cada ingeniero no debe memorizar flags Metro personalizados.
Extiende expo/tsconfig.base: TypeScript estricto desde la plantilla - la deriva de tsconfig personalizado rompe las rutas tipadas de Expo Router y los tipos de autolinking.
Usa app.config.ts para entornos: La configuración dinámica supera los archivos app.json duplicados - impulsa variantes con variables de entorno APP_VARIANT o BRAND.
Elige la plantilla más pequeña que se ajuste: blank-typescript para aprender; tabs solo cuando la navegación es un alcance del primer día - elimina el boilerplate no utilizado inmediatamente.
Organiza por característica, no solo por capas: features/orders/ posee pantallas, hooks y presentadores - el components/ global es solo para primitivos del sistema de diseño.
Una exportación pública por característica: Los archivos de rutas importan OrdersScreen desde features/orders - sin importaciones profundas entre características en hooks/useOrder.ts.
Directorio app/ delgado: Los archivos de Expo Router re-exportan pantallas de características - la lógica de negocio no vive al lado de _layout.tsx.
Inicia monorepos con pnpm + Turborepo cuando compartes UI: apps/mobile + packages/ui con workspace:* - agrega Nx cuando los generadores y gráficos afectados justifican la complejidad.
Deja que SDK 57 configure Metro primero: La detección automática de monorepo supera los watchFolders escritos a mano - personaliza solo cuando doctor y compilaciones prueban una brecha.
Levanta o aísla conscientemente los enlaces simbólicos de pnpm: nodeLinker: hoisted evita muchos bugs de symlink de Metro - documenta la elección en README para la incorporación.
Nunca duplica react-native en el gráfico: Dos copias nativas causan "Invalid hook call" y redboxes oscuros - verifica npx expo-doctor y why react-native en CI.
Declara peerDependencies en paquetes compartidos: Las bibliotecas del espacio de trabajo deben peer react, react-native y expo - las apps proporcionan la única versión instalada.
Usa etiquetas de Nx para límites: scope:orders no puede importar internos de scope:billing - aplica con @nx/enforce-module-boundaries en organizaciones en crecimiento.
Ejecuta tareas afectadas en CI: nx affected -t lint,typecheck,test mantiene rápidos los PRs de monorepo - las ejecuciones de repositorio completo no escalan más allá de una docena de paquetes.
Etiqueta blanca con configuración, no bifurcaciones: apps/acme y apps/globex comparten packages/core - los tokens de marca se inyectan a través de BrandProvider, no pantallas copy-paste.
Separa projectId de EAS por binario de aplicación: Los sabores de etiqueta blanca necesitan credenciales, variables de entorno y canales de actualización distintos - un projectId por bundle ID.
Gitignore carpetas nativas bajo CNG: Los ios//android/ confirmados bloquean las actualizaciones de SDK - regenera en EAS Build o expo prebuild --clean.
Documenta la verificación de la primera ejecución: Un script que ejecuta expo-doctor, tsc --noEmit y una compilación de dev-client - los nuevos empleados prueban la cadena de herramientas en un comando.
Ignora .env.local, confirma .env.example: Los secretos específicos de la máquina se quedan locales - el env de ejemplo documenta las claves EXPO_PUBLIC_* requeridas sin valores.
Alinea Babel y Metro con la plantilla: Los plugins personalizados pertenecen a la configuración documentada - la deriva silenciosa de Babel rompe Fast Refresh y Reanimated.
Elige Turborepo o Nx, no ambos orquestadores: Un propietario de gráfico de tareas - mezclar confunde los scripts dev y las claves de caché.
Revisa la estructura de carpetas en - 15 ingenieros: Los diseños solo de capas colapsan bajo equipos de características paralelas - programa una migración antes de que los ciclos de importación fuercen una reescritura.

Preguntas Frecuentes

¿Cuándo debemos adoptar un monorepo?

Cuando dos o más apps o un paquete de UI compartido se envían desde el mismo equipo.
Los equipos de aplicación única deben mantenerse en un solo repositorio hasta que el dolor de duplicación sea medible.

¿Turborepo o Nx para Expo?

Turborepo para almacenamiento en caché más simple y espacios de trabajo pnpm.
Nx cuando necesitas generadores, aplicación de límites y gráficos afectados a escala.

¿Pueden múltiples apps de Expo compartir un node_modules?

Sí en la raíz del espacio de trabajo con pnpm - cada app aún necesita su propio app.config y proyecto EAS.
Metro debe resolver una instancia de react-native.

Relacionado

Conceptos Básicos de Configuración del Proyecto - layout, scripts, and first-run verification
Plantillas create-expo-app - picking the right starter
Estructura de Carpetas para Características - feature slices vs layers
Monorepo con Turborepo - shared packages and caching
Paquetes Compartidos y Resolución de Metro - watchFolders and symlinks
Múltiples Apps en Un Repositorio - white-label patterns

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

Mejores Prácticas de Configuración del Proyecto

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

Scaffold con un pin de plantilla SDK: npx create-expo-app@latest --template default@sdk-57 - actualizar después cuesta más que empezar con el SDK soportado.
Ejecuta expo-doctor el primer día: Corrige el desfase de versiones antes del primer PR de características - doctor detecta desajustes de configuración y dependencias temprano.
Confirma archivos de bloqueo con la app: CI y EAS deben resolver el mismo árbol que el desarrollo local - las instalaciones flotantes ocultan el desfase nativo/JS hasta TestFlight.
Mantén los scripts de package.json aburridos: start, ios, android, lint, typecheck - cada ingeniero no debe memorizar flags Metro personalizados.
Extiende expo/tsconfig.base: TypeScript estricto desde la plantilla - la deriva de tsconfig personalizado rompe las rutas tipadas de Expo Router y los tipos de autolinking.
Usa app.config.ts para entornos: La configuración dinámica supera los archivos app.json duplicados - impulsa variantes con variables de entorno APP_VARIANT o BRAND.
Elige la plantilla más pequeña que se ajuste: blank-typescript para aprender; tabs solo cuando la navegación es un alcance del primer día - elimina el boilerplate no utilizado inmediatamente.
Organiza por característica, no solo por capas: features/orders/ posee pantallas, hooks y presentadores - el components/ global es solo para primitivos del sistema de diseño.
Una exportación pública por característica: Los archivos de rutas importan OrdersScreen desde features/orders - sin importaciones profundas entre características en hooks/useOrder.ts.
Directorio app/ delgado: Los archivos de Expo Router re-exportan pantallas de características - la lógica de negocio no vive al lado de _layout.tsx.
Inicia monorepos con pnpm + Turborepo cuando compartes UI: apps/mobile + packages/ui con workspace:* - agrega Nx cuando los generadores y gráficos afectados justifican la complejidad.
Deja que SDK 57 configure Metro primero: La detección automática de monorepo supera los watchFolders escritos a mano - personaliza solo cuando doctor y compilaciones prueban una brecha.
Levanta o aísla conscientemente los enlaces simbólicos de pnpm: nodeLinker: hoisted evita muchos bugs de symlink de Metro - documenta la elección en README para la incorporación.
Nunca duplica react-native en el gráfico: Dos copias nativas causan "Invalid hook call" y redboxes oscuros - verifica npx expo-doctor y why react-native en CI.
Declara peerDependencies en paquetes compartidos: Las bibliotecas del espacio de trabajo deben peer react, react-native y expo - las apps proporcionan la única versión instalada.
Usa etiquetas de Nx para límites: scope:orders no puede importar internos de scope:billing - aplica con @nx/enforce-module-boundaries en organizaciones en crecimiento.
Ejecuta tareas afectadas en CI: nx affected -t lint,typecheck,test mantiene rápidos los PRs de monorepo - las ejecuciones de repositorio completo no escalan más allá de una docena de paquetes.
Etiqueta blanca con configuración, no bifurcaciones: apps/acme y apps/globex comparten packages/core - los tokens de marca se inyectan a través de BrandProvider, no pantallas copy-paste.
Separa projectId de EAS por binario de aplicación: Los sabores de etiqueta blanca necesitan credenciales, variables de entorno y canales de actualización distintos - un projectId por bundle ID.
Gitignore carpetas nativas bajo CNG: Los ios//android/ confirmados bloquean las actualizaciones de SDK - regenera en EAS Build o expo prebuild --clean.
Documenta la verificación de la primera ejecución: Un script que ejecuta expo-doctor, tsc --noEmit y una compilación de dev-client - los nuevos empleados prueban la cadena de herramientas en un comando.
Ignora .env.local, confirma .env.example: Los secretos específicos de la máquina se quedan locales - el env de ejemplo documenta las claves EXPO_PUBLIC_* requeridas sin valores.
Alinea Babel y Metro con la plantilla: Los plugins personalizados pertenecen a la configuración documentada - la deriva silenciosa de Babel rompe Fast Refresh y Reanimated.
Elige Turborepo o Nx, no ambos orquestadores: Un propietario de gráfico de tareas - mezclar confunde los scripts dev y las claves de caché.
Revisa la estructura de carpetas en - 15 ingenieros: Los diseños solo de capas colapsan bajo equipos de características paralelas - programa una migración antes de que los ciclos de importación fuercen una reescritura.

Preguntas Frecuentes

¿Cuándo debemos adoptar un monorepo?

Cuando dos o más apps o un paquete de UI compartido se envían desde el mismo equipo.
Los equipos de aplicación única deben mantenerse en un solo repositorio hasta que el dolor de duplicación sea medible.

¿Turborepo o Nx para Expo?

Turborepo para almacenamiento en caché más simple y espacios de trabajo pnpm.
Nx cuando necesitas generadores, aplicación de límites y gráficos afectados a escala.

¿Pueden múltiples apps de Expo compartir un node_modules?

Sí en la raíz del espacio de trabajo con pnpm - cada app aún necesita su propio app.config y proyecto EAS.
Metro debe resolver una instancia de react-native.

Relacionado

Conceptos Básicos de Configuración del Proyecto - layout, scripts, and first-run verification
Plantillas create-expo-app - picking the right starter
Estructura de Carpetas para Características - feature slices vs layers
Monorepo con Turborepo - shared packages and caching
Paquetes Compartidos y Resolución de Metro - watchFolders and symlinks
Múltiples Apps en Un Repositorio - white-label patterns

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

Mejores Prácticas de Configuración del Proyecto

Preguntas Frecuentes

Relacionado

Buscar en la documentación

Mejores Prácticas de Configuración del Proyecto

Preguntas Frecuentes

Relacionado