Conceptos básicos de estándares

10 ejemplos de convenciones de equipo más allá de ESLint - reglas de nombres, carpetas y toque nativo que sobreviven a los cambios de SDK y nuevos miembros. Siete básicos y tres intermedios.

Requisitos previos

Comienza desde un proyecto Expo SDK 57 con TypeScript y Expo Router. Los estándares viven en docs/CONTRIBUTING.md (o docs/standards.md) y se aplican en la revisión de PR - no solo en el chat.

npx create-expo-app@latest MyApp --template default@sdk-57
cd MyApp
npx expo lint

{
  "dependencies": {
    "expo": "~57.0.4",
    "react": "19.2.3",
    "react-native": "0.86.0"
  }
}

Herramientas: Estos ejemplos están dirigidos a Expo SDK 57 (expo ~57.0.4), React Native 0.86.0, y React 19.2.3. La configuración de ESLint está en Conceptos básicos de lint; las reglas del proyecto están en Lista de verificación de reglas del proyecto Expo.

Ejemplos básicos

1. Tabla de convenciones de nombres

Publica una tabla - debate una vez, consulta para siempre.

// src/features/order-history/components/OrderSummaryCard.tsx
export function OrderSummaryCard({ orderId }: { orderId: string }) {
  return null;
}

• El nombre del archivo coincide con la exportación predeterminada para componentes - grep e IDE jump-to-definition se mantienen predecibles
• Los Hooks viven en hooks/ dentro de la característica o en src/shared/hooks/ cuando es entre características
• Los nombres de parámetros de ruta en Expo Router usan camelCase en el código (orderId) incluso cuando el segmento de URL está en kebab-case

Relacionado: Prettier y clasificación de importaciones - el formato no es nomenclatura | Estándares de codificación y guías de estilo - libro de recetas de aplicación

2. Distribución de carpetas - Greenfield Expo

Alinéate con Conceptos básicos de arquitectura móvil: app/ delgado, src/features/ grueso.

MyApp/
├── app/                          # solo rutas - sin lógica de negocios
│   ├── (tabs)/
│   │   ├── index.tsx
│   │   └── orders/
│   │       └── [id].tsx
│   └── _layout.tsx
├── src/
│   ├── shared/                   # api, primitivas de ui, asistentes de config
│   ├── entities/                 # User, Order - sustantivos de dominio
│   └── features/
│       ├── auth/
│       │   ├── index.ts          # API pública
│       │   ├── screens/
│       │   ├── components/
│       │   ├── hooks/
│       │   └── model/
│       └── orders/
├── plugins/                      # config plugins - zona de toque nativo
├── app.config.ts
├── eas.json
└── docs/
    ├── CONTRIBUTING.md           # los estándares viven aquí
    └── adr/

• Los archivos app/ deben re-exportar pantallas de características - una línea cuando sea posible
• src/features/<name>/index.ts es la única ruta de importación que usan otros módulos
• Los cambios en plugins/ y app.config.ts desencadenan revisión nativa - ver reglas de toque nativo a continuación
• No crees un cajón de basura src/utils/ - promueve a shared/ con un propósito nombrado

Relacionado: Lista de verificación de reglas del proyecto Expo - Reglas de carpetas de nivel 2

3. API pública de características - Sin importaciones profundas

// ✅ Correcto - el consumidor importa del barril de características
import { OrdersScreen, type Order } from "@/features/orders";
 
// ❌ Incorrecto - se acopla a refactor interno
import { OrderRow } from "@/features/orders/components/OrderRow";

// src/features/orders/index.ts
export { OrdersScreen } from "./screens/OrdersScreen";
export type { Order } from "./model/types";
// No exportes OrderRow a menos que otra característica realmente lo necesite

• Las exportaciones de barril son intencionales - los componentes internos se mantienen privados hasta que una segunda característica los necesite
• ESLint no-restricted-imports puede forzar rutas @/features/*/* - ver Reglas de ESLint personalizadas para RN
• Cuando dos características comparten UI, mueve el componente a src/shared/ui/ - no exportes interiores hermanos

4. Disciplina de archivo de ruta

// app/(tabs)/orders/index.tsx
export { OrdersScreen as default } from "@/features/orders";

// app/orders/[id].tsx - el análisis de parámetros se mantiene en la capa de ruta
import { useLocalSearchParams } from "expo-router";
import { OrderDetailScreen } from "@/features/orders";
 
export default function OrderDetailRoute() {
  const { id } = useLocalSearchParams<{ id: string }>();
  if (!id) return null;
  return <OrderDetailScreen orderId={id} />;
}

• Analiza parámetros una vez en el archivo de ruta; pasa propiedades tipadas a la pantalla
• Los Layouts (_layout.tsx) poseen proveedores y configuración de stack/tab - no reglas de negocios de características
• Las rutas modales siguen Reglas de navegación y enrutamiento - un patrón de presentación por aplicación

5. Reglas de toque nativo - Quién puede editar qué

# Después de cambio de plugin o SDK - obligatorio en equipos CNG
npx expo prebuild --clean
git diff ios/ android/

• Los equipos CNG gitignore carpetas nativas - la edición manual de Info.plist garantiza la sobrescritura de EAS
• Los repositorios host Brownfield siguen Conceptos básicos de Brownfield - bumps de versión de artefactos, no bundles de copiar-pegar
• Cualquier excepción necesita un ADR en docs/adr/ - "temporal" sin ADR se convierte en años de desviación

Relacionado: Reglas de módulo nativo - cuando JS no es suficiente

6. Nombres de rama y ticket

feat/SHIP-412-order-summary-sheet
fix/SHIP-419-crash-on-logout
chore/upgrade-expo-sdk-57
spike/expo-ui-tab-bar
release/2.6.0
hotfix/2.5.1

• El prefijo coincide con el tipo de confirmación convencional - feat, fix, chore, spike
• ID de ticket requerido cuando tu org usa Jira/Linear - los cherry-picks dependen de la trazabilidad
• spike/* nunca se fusiona a main sin resultado de ADR - ver Spikes, PoCs y nueva arquitectura
• Las actualizaciones de SDK usan ramas dedicadas chore/upgrade-* - no se mezclan con trabajo de características

Relacionado: Conceptos básicos de Git para equipos móviles

7. Nombres de entorno y secreto

EAS environment:     development | preview | production
.env files:          .env.local (gitignored), .env.example (committed)
Public runtime vars: EXPO_PUBLIC_* only - never secrets
Config:              app.config.ts reads process.env at build time

// app.config.ts - pattern
const IS_DEV = process.env.APP_ENV === "development";
 
export default {
  expo: {
    extra: {
      apiUrl: process.env.EXPO_PUBLIC_API_URL,
    },
  },
};

• EXPO_PUBLIC_* se incrusta en tiempo de compilación - trátalas como visibles para los usuarios; ver Reglas de seguridad para móviles
• .env.example documenta cada clave requerida con valores de marcador de posición - la incorporación copia a .env.local
• Los nombres de perfil en eas.json coinciden con development / preview / production - no staging2

Ejemplos intermedios

8. Nombres de paquete de monorepo

apps/
  mobile/                 # Aplicación Expo - consumidor principal
packages/
  ui/                     # @myorg/ui - componentes RN compartidos
  api-client/             # @myorg/api-client - capa de búsqueda
  tsconfig/               # @myorg/tsconfig - bases compartidas

{
  "name": "@myorg/ui",
  "main": "src/index.ts",
  "peerDependencies": {
    "react": "19.2.3",
    "react-native": "0.86.0"
  }
}

• Un lockfile en la raíz del repo - las aplicaciones no flotan árboles independientes
• Los paquetes exponen src/index.ts - la misma regla de barril que las características
• Las dependencias de pares fijan RN/React - el paquete del espacio de trabajo no debe empaquetar React duplicado
• El pipeline Turbo ejecuta los mismos scripts lint / typecheck - Puertas de calidad de CI

9. Estándares de módulo nativo y complemento de configuración

Al agregar un complemento de configuración o módulo nativo personalizado:

plugins/
  withMySdk.ts            # complemento de configuración
src/modules/
  my-sdk/                 # módulo Expo local opcional
    expo-module.config.json
    ios/
    android/

# Lista de verificación de PR para PR de toque nativo
npx expo prebuild --clean
npx expo-doctor
eas build --profile preview --platform all

• El id del complemento coincide con el nombre del paquete npm o la función with* - un complemento por archivo
• Documenta permisos de iOS/Android agregados en la plantilla de PR - la revisión de tienda lee estas cadenas
• Compatibilidad de Nueva Arquitectura anotada en ADR - RN 0.86 predetermina NA en greenfield
• Sigue Reglas de módulo nativo antes de expo prebuild

10. Plantilla de documento de estándares

Confirma docs/CONTRIBUTING.md con viñetas aplicables - enlaza desde la plantilla de PR.

# Estándares móviles (SDK 57)
 
## Nombres
- Componentes: Archivos PascalCase que coinciden con la exportación
- Rutas: carpetas kebab-case bajo app/
 
## Importaciones
- Características: importar solo desde @/features/<name>
- Sin exportaciones predeterminadas en hooks/utils - solo exportaciones nombradas
 
## Toque nativo
- Sin ediciones manuales de ios/ android/ bajo CNG
- Los cambios de plugins/ requieren diferencia de prebuild --clean en PR
 
## Revisión
- PR de UI: captura de pantalla de iOS + Android o build_id
- PR de toque nativo: revisor de plataforma requerido
 
## Excepciones
- Registra en docs/adr/NNNN-title.md - enlaza en PR

• Revisite trimestralmente y después de cada bump de SDK - Seguimiento de depreciación y EOL
• Casilla de verificación de plantilla de PR - "He leído CONTRIBUTING.md" supera recordatorios de Slack
• Primer día de incorporación - asigna lectura de Mejores prácticas de reglas de Expo + este documento

Preguntas frecuentes

Relacionado

• Estándares de codificación y guías de estilo - aplicación de lint + revisión
• Lista de verificación de reglas del proyecto Expo - 25 innegociables
• Conceptos básicos de Linting - configuración flat de ESLint 9
• Conceptos básicos de arquitectura móvil - límites de capa
• Reglas de módulo nativo - gobernanza de cambios nativos
• Mejores prácticas de gobernanza - resumen condensado de 25 puntos

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