Busque em todas as páginas da documentação
Vinte e cinco regras inegociáveis para aplicativos Expo de fácil manutenção no React Native 0.86 e Expo SDK 57. Estas regras cobrem o scaffolding do projeto, configuração, layout de pastas, Geração Nativa Contínua (CNG), higiene de dependências e convenções de equipe. Trate violações como bloqueadores de merge, a menos que um ADR documente uma exceção.
docs/adr/ - "vamos consertar mais tarde" sem um ADR se torna dívida permanente.Fixe o SDK no momento do scaffold: Comece com npx create-expo-app@latest --template default@sdk-57 para que expo resolva para ~57.0.4 - atualizar três SDKs em um PR é uma fábrica de conflitos de merge.
npx expo-doctor passa antes que o primeiro PR de funcionalidade seja mesclado.latest sem um pin de SDK no CI ou na documentação de onboarding do README.app.config.ts é a única fonte da verdade: A configuração dinâmica suporta ambientes, helpers tipados e plugins condicionais; um app.json estático isolado não escala além de um único flavor de build.
ExpoConfig tipado de app.config.ts e exclua campos duplicados em app.json.npx expo config --type public antes de cada submissão para a loja.Nunca comite segredos em extra ou EXPO_PUBLIC_*: Valores prefixados com EXPO_PUBLIC_ são inline no tempo de bundle - chaves de API, segredos de assinatura e tokens de administrador pertencem ao EAS Secrets, não ao git.
extra e leia com Constants.expoConfig.process.env.STRIPE_SECRET_KEY em qualquer lugar no código do aplicativo ou configuração.Comite lockfiles com o aplicativo: package-lock.json, pnpm-lock.yaml ou yarn.lock devem corresponder ao que o EAS Build e o CI resolvem - instalações flutuantes escondem desvios nativos/JS até o TestFlight.
package.json.Use npx expo install para todos os pacotes Expo: npm install expo-camera@latest manual pode puxar stubs JS que não correspondem aos binários nativos do SDK 57 - TypeScript compila enquanto a produção falha.
npx expo install --fix após atualizações de SDK, depois expo-doctor.Mapeie perfis de build EAS para ambientes: Perfis eas.json declaram environment: development | preview | production para que credenciais e variáveis de ambiente se resolvam da mesma forma no CI e em laptops.
eas env:pull --environment development para onboarding - não copiar e colar do Slack.Diretório app/ fino: Arquivos do Expo Router reexportam telas de funcionalidades - a lógica de negócios, hooks e clientes de API não vivem ao lado de _layout.tsx.
app/(tabs)/orders/index.tsx exporta OrdersScreen de features/orders.app/ para manter arquivos com ~20 linhas.Organize por funcionalidade, não apenas por camada: features/orders/ possui telas, hooks, apresentadores e tipos específicos de funcionalidade - components/ global é apenas para primitivas do sistema de design.
screens/, hooks/ e services/ onde cada funcionalidade toca em cada pasta.Uma exportação pública por funcionalidade: Arquivos de rota importam do barril features/orders - sem importações profundas entre funcionalidades em features/billing/hooks/useInvoice.ts.
no-restricted-imports em monorepos.packages/core documentadas no README.Mantenha scripts do package.json simples: start, ios, android, lint, typecheck, test - cada engenheiro não deve memorizar flags do Metro únicas.
postinstall, eas-build-pre-install) no README.Estenda expo/tsconfig.base: TypeScript rigoroso do template - desvios personalizados de tsconfig quebram rotas tipadas do Expo Router e tipos de autolinking.
@/* em moduleNameMapper do Jest ao usar aliases de caminho.skipLibCheck: false entra em conflito com tipagens de RN de terceiros - siga os padrões do Expo.Coloque os testes ao lado do código fonte: Button.test.tsx ao lado de Button.tsx ou em features/orders/__tests__/ - __tests__ distantes na raiz do repositório param de ser atualizados.
app/ - use __tests__ ou *.test.tsx em src/ e features/.npm test -- --ci em cada PR.Ignore ios/ e android/ sob CNG: Pastas nativas commitadas de um SDK mais antigo bloqueiam os templates de prebuild do RN 0.86 - regenere no EAS Build ou npx expo prebuild --clean.
expo prebuild após atualizações de SDK.Expresse mudanças nativas como plugins de configuração: Editar manualmente Info.plist ou AndroidManifest.xml gerados é perdido no npx expo prebuild --clean - o padrão do SDK 57.
Comece com Expo Go, passe para builds de desenvolvimento: Expo Go é bom para aprender; adicione expo-dev-client assim que depender de módulos nativos não incluídos no Expo Go.
development produz clientes de desenvolvimento instaláveis para QA.Uma instância react-native no grafo de dependências: Cópias nativas duplicadas causam "Chamada de hook inválida" e obscurecem redboxes - npx expo-doctor e npm why react-native no CI.
npx expo install do diretório do aplicativo; eleve conscientemente com nodeLinker do pnpm.node_modules/react-native aninhado de pacotes de workspace conflitantes.Deixe o SDK 57 configurar o Metro primeiro: Detecção automática de monorepo supera watchFolders escritos manualmente - personalize apenas quando o doctor e os builds provarem uma lacuna.
metro.config.js que link para a falha que ela corrige.Registre a raiz com registerRootComponent: Pontos de entrada bare ou brownfield que pulam a inicialização do Expo perdem a inicialização do autolinking e falham misteriosamente ao chamar módulos nativos.
MainComponent / moduleName corresponde ao registro JS em embeds brownfield.expo entrada em package.json main.owner para projetos de organização: Omitir "owner": "org-slug" em app.config roteia builds e credenciais para uma conta pessoal em vez da equipe.projectId por binário de aplicativo: Reutilizar um projeto EAS entre IDs de aplicativo não relacionados colide credenciais e canais de atualização.projectId estável: Nunca rotacione - serviços EAS dependem do UUID pela vida útil do aplicativo.Tokens de robô para CI, não senhas pessoais: Usuários robôs com escopo de organização sobrevivem a saídas de funcionários e fornecem um caminho de revogação auditável.
Ignore .env.local, comite .env.example: Segredos específicos da máquina permanecem locais - o exemplo de env documenta as chaves EXPO_PUBLIC_* necessárias sem valores.
eas env:pull como segundo passo após npm install..env.production com segredos reais no histórico do git.Execute expo-doctor no CI em cada PR: Captura versões de módulos nativos incompatíveis, campos de configuração inválidos e desvios de dependência antes do merge.
tsc --noEmit e expo lint.Documente a verificação da primeira execução: Um script que executa expo-doctor, tsc --noEmit e opcionalmente um build de dev-client - novos contratados provam a toolchain em um comando.
npm run verify ou scripts/verify-toolchain.sh.ADR para cada escolha arquitetural não padrão: Configuração Metro personalizada, pastas nativas commitadas, navegação não-Expo ou armazenamento seguro pulado - registre o contexto e a data de revisão.
docs/adr/NNNN-title.md com status Aceito | Suplantado | Obsoleto.Atualize SDKs sequencialmente: Pular múltiplas versões de SDK em um PR acumula mudanças que quebram - passe pelos changelogs entre merges, mesmo que o alvo final seja SDK 57.
Não para aplicativos Expo CNG padrão - ignore-os e deixe o EAS Build ou expo prebuild regenerar. Aplicativos Brownfield com código nativo mantido manualmente são a exceção; documente essa escolha em um ADR.
Prefira app.config.ts para qualquer aplicativo com mais de um ambiente. Mantenha um app.json mínimo apenas se a ferramenta exigir, mas evite duplicar campos em ambos os arquivos.
Para aprender, demonstrações e trabalho inicial de UI sem módulos nativos personalizados. Mude para expo-dev-client antes de integrar pagamentos, push, tarefas em segundo plano ou qualquer pacote não incluído no Expo Go.
Revisão de código, max-lines ESLint opcional em app/**, e barris de funcionalidade dos quais as telas devem importar. Arquivos de rota devem ser lidos como um índice, não um romance.
EXPO_PUBLIC_* apenas para valores seguros para serem enviados no bundle do cliente (URLs de API públicas, chaves de analytics destinadas ao cliente). Segredos do servidor, chaves de assinatura e tokens de administrador permanecem no EAS Secrets e no código do lado do servidor.
As mesmas regras se aplicam; adicione: um lockfile, uma instância react-native, npx expo install de cada diretório de aplicativo e aplicação de limites Nx ou Turborepo para importações entre funcionalidades.
Em cada PR no CI, localmente após npm install, e obrigatoriamente antes de mesclar qualquer branch de atualização de SDK.
Aplicativos sempre comitam lockfiles. Pacotes internos do workspace consumidos apenas via workspace:* seguem o lockfile raiz - não flutue versões dentro de packages/ui.
No mínimo: start, alvos de plataforma (ios/android ou expo run:*), lint e typecheck. Adicione test assim que o Jest for configurado. O CI deve chamar os mesmos nomes que os desenvolvedores usam localmente.
Quando a escolha afeta código nativo, canais de lançamento, postura de segurança ou é difícil de reverter - módulos nativos personalizados, ios/ commitado, pinning de certificado ou pular expo-secure-store para tokens.
Variantes app.config separadas por marca (APP_VARIANT), IDs de bundle distintos, projectId EAS separado por binário, packages/core compartilhado - não código de funcionalidade bifurcado por cliente.
Os padrões do RN 0.86 favorecem a Nova Arquitetura - as regras do projeto ainda se aplicam. Atualizações de SDK exigem a leitura de itens do changelog nativo; CNG e expo-doctor importam mais, não menos.
expo-doctor, tsc --noEmit, expo lint e testes unitários (jest --ci). Adicione EAS Build em main quando os módulos nativos excederem o Expo Go.
Apenas através de barris públicos ou pacotes compartilhados - nunca importe profundamente hooks internos de outra funcionalidade. Acoplamentos entre funcionalidades pertencem a packages/core com APIs explícitas.
Versões da Stack: Esta página foi escrita para React 19.2.3, React Native 0.86.0 e Expo SDK 57 (
expo~57.0.4).
Revisado por Chris St. John·Última atualização: 9 de jul. de 2026