Melhores Práticas da Plataforma Expo
Um resumo condensado das 25 melhores práticas mais importantes extraídas de cada página desta seção.
//
Busque em todas as páginas da documentação
Um resumo condensado das 25 melhores práticas mais importantes extraídas de cada página desta seção.
Fixe o SDK no momento do scaffold: Use npx create-expo-app@latest --template default@sdk-57 (ou equivalente) para que expo comece em ~57.0.4 - atualizar mais tarde é mais difícil do que começar com o SDK suportado atual.
Execute expo-doctor após cada scaffold ou upgrade: npx expo-doctor detecta versões de módulos nativos incompatíveis, campos inválidos em app.json e desvios de configuração antes de mesclar um branch de upgrade.
Sempre use npx expo install para pacotes Expo: npm install manual pode puxar stubs de JS que não correspondem aos binários nativos para o SDK 57 - o sucesso da compilação não garante estabilidade em tempo de execução.
Trate app.config.ts como a fonte da verdade: A configuração dinâmica suporta ambientes, helpers tipados e plugins condicionais; apenas app.json estático não escala além de um único flavor de build.
Nunca comite segredos em extra ou EXPO_PUBLIC_*: Prefixe variáveis públicas com EXPO_PUBLIC_ apenas para valores seguros para serem enviados no bundle do cliente; segredos do servidor pertencem ao EAS Secrets.
Audite o manifesto público antes do lançamento: Execute npx expo config --type public e confirme que nenhuma chave privada, URL interna ou endpoint de staging vazou para a configuração em tempo de build.
Leia a configuração em tempo de execução via Constants.expoConfig: Não use import app.json no código de recursos - o manifesto processado do pipeline de plugins de configuração do Expo é o que realmente é enviado.
Comece com Expo Go, passe para builds de desenvolvimento: Expo Go é bom para aprendizado e demonstrações; adicione expo-dev-client assim que você depender de módulos nativos não incluídos no Expo Go.
Reconstrua o dev client após cada atualização de SDK: Atualizações OTA (eas update) mudam apenas o JavaScript - os shells nativos do expo-dev-client devem ser reconstruídos com eas build --profile development.
Registre o root 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.
Prefira requireNativeModule do expo em aplicativos: Pacotes de biblioteca devem importar de expo-modules-core para evitar ciclos de dependência peer; o código do aplicativo pode usar o re-export do expo.
Mapeie perfis de build EAS para ambientes: Use as chaves environment do eas.json (development, preview, production) para que credenciais e variáveis de ambiente sejam resolvidas consistentemente em CI e localmente.
Puxe variáveis de ambiente com eas env:pull: Sincronize segredos gerenciados pela equipe em .env.local para desenvolvimento local sem copiar valores para chat ou drives compartilhados.
Atualize SDKs sequencialmente: Pular várias versões de SDK em um único PR agrava as alterações que quebram - passe de 54 → 55 → 56 → 57, lendo cada changelog entre os merges.
Exclua pastas nativas obsoletas após upgrades CNG: ios/ e android/ commitados de templates de prebuild de um SDK mais antigo para RN 0.86 - ignore-os e deixe o EAS Build regenerá-los.
Expresse alterações nativas como plugins de configuração: Editar manualmente arquivos Info.plist ou AndroidManifest.xml gerados é perdido em npx expo prebuild --clean (o padrão do SDK 57).
Escreva plugins de configuração idempotentes: Plugins que anexam substituições de regex duas vezes corrompem projetos nativos - projete plugins para serem seguros em execuções repetidas de prebuild.
Defina 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.
Um projectId por binário de aplicativo: Reutilizar um projeto EAS entre IDs de bundle não relacionados colide credenciais, canais de atualização e variáveis de ambiente.
Defina engenheiros como Desenvolvedor por padrão: Reserve Proprietário para cobertura de fator de risco (dois proprietários no máximo); Administrador para líderes que gerenciam faturamento e convites - não para todos os ICs.
Use 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.
Mantenha slug flexível, projectId estável: Renomeie slugs de exibição quando a marca muda; nunca roteie projectId - os serviços EAS dependem do UUID pela vida útil do aplicativo.
Corresponda MainComponent / moduleName ao registro JS: Aplicativos bare cuja entrada nativa diz "MyApp" enquanto o JS registra "main" mostram uma tela em branco sem erro de JS óbvio.
Lance SharedObjects explicitamente: Handles nativos de longa duração de módulos Expo (players, sensores) vazam memória até release() ou o hook do pacote limpar na desmontagem.
Leia as notas de lançamento do SDK 57 e RN 0.86 antes de atualizar: Hermes, Reanimated e os padrões da Nova Arquitetura mudam o comportamento mesmo quando o TypeScript ainda compila - trate o changelog como parte da lista de verificação de upgrade.
app.config.ts e plugins de configuração, não pastas ios//android/ editadas manualmente.npx expo-doctor sem falhas.eas build --profile development limpo em CI.EXPO_PUBLIC_API_URL vinculado a um ambiente preview do EAS - não codificado diretamente no código.eas env em vez de manter arquivos app.config paralelos.eas build para produção após atualizar o SDK 57; use OTA apenas para alterações de JS/ativos dentro da mesma versão de runtime.extra ou variáveis de ambiente sem prefixo que são incorporadas no bundle JS.npx expo config --type public antes de cada lançamento.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