Melhores Práticas de Configuração de Projeto

Um resumo condensado das 25 melhores práticas mais importantes, extraídas de todas as páginas desta seção.

Scaffold com um pin de template do SDK: npx create-expo-app@latest --template default@sdk-57 - atualizar mais tarde custa mais do que começar no SDK suportado.
Execute expo-doctor no primeiro dia: Corrija o descompasso de versão antes do primeiro PR de feature - doctor pega incompatibilidades de configuração e dependências cedo.
Commite os lockfiles com o app: CI e EAS devem resolver a mesma árvore que o desenvolvimento local - instalações flutuantes escondem o descompasso nativo/JS até o TestFlight.
Mantenha os scripts do package.json simples: start, ios, android, lint, typecheck - cada engenheiro não deve memorizar flags do Metro pontuais.
Estenda expo/tsconfig.base: TypeScript rigoroso do template - desvios customizados no tsconfig quebram rotas tipadas do Expo Router e tipos de autolinking.
Use app.config.ts para ambientes: Configuração dinâmica supera arquivos app.json duplicados - controle variantes com variáveis de ambiente APP_VARIANT ou BRAND.
Escolha o menor template que se encaixe: blank-typescript para aprendizado; tabs apenas quando a navegação é escopo do primeiro dia - delete boilerplate não utilizado imediatamente.
Organize por feature, não apenas por camada: features/orders/ possui telas, hooks e apresentadores - components/ global é apenas para primitivas do design system.
Uma exportação pública por feature: Arquivos de rota importam OrdersScreen de features/orders - sem imports profundos entre features em hooks/useOrder.ts.
Diretório app/ enxuto: Arquivos do Expo Router re-exportam telas de features - a lógica de negócios não vive ao lado de _layout.tsx.
Comece monorepos com pnpm + Turborepo ao compartilhar UI: apps/mobile + packages/ui com workspace:* - adicione Nx quando geradores e grafos de affected justificarem a complexidade.
Deixe o SDK 57 configurar o Metro primeiro: Detecção automática de monorepo supera watchFolders escritos manualmente - personalize apenas quando doctor e builds provarem uma lacuna.
Faça hoist ou isole os symlinks do pnpm conscientemente: nodeLinker: hoisted evita muitos bugs de symlink do Metro - documente a escolha no README para onboarding.
Nunca duplique react-native no grafo: Duas cópias nativas causam "Invalid hook call" e obscurecem redboxes - npx expo-doctor e verificações de why react-native em CI.
Declare peerDependencies em pacotes compartilhados: Bibliotecas de workspace devem ter react, react-native e expo como peerDependencies - os apps fornecem a única versão instalada.
Use tags Nx para limites: scope:orders não pode importar internos de scope:billing - imponha com @nx/enforce-module-boundaries em organizações em crescimento.
Execute tarefas afetadas em CI: nx affected -t lint,typecheck,test mantém PRs de monorepo rápidos - execuções de repositório completo não escalam além de uma dúzia de pacotes.
White-label com configuração, não forks: apps/acme e apps/globex compartilham packages/core - tokens de marca são injetados via BrandProvider, não copiando e colando telas.
Separe o projectId do EAS por binário do app: Flavors de white-label precisam de credenciais, variáveis de ambiente e canais de atualização distintos - um projectId por bundle ID.
Gitignore pastas nativas sob CNG: ios//android/ commitados bloqueiam upgrades de SDK - regenere em EAS Build ou expo prebuild --clean.
Documente a verificação da primeira execução: Um script que executa expo-doctor, tsc --noEmit e um build de cliente de desenvolvimento - novos contratados provam a toolchain em um comando.
Ignore .env.local, commite .env.example: Segredos específicos da máquina permanecem locais - o env de exemplo documenta as chaves EXPO_PUBLIC_* necessárias sem valores.
Alinhe Babel e Metro com o template: Plugins customizados pertencem à configuração documentada - desvios silenciosos do Babel quebram Fast Refresh e Reanimated.
Escolha Turborepo ou Nx, não ambos os orquestradores: Um único dono do grafo de tarefas - misturar confunde scripts dev e chaves de cache.
Revise a estrutura de pastas com ~15 engenheiros: Layouts apenas por camada colapsam sob equipes de feature paralelas - agende uma migração antes que ciclos de import forcem uma reescrita.

FAQs

Quando devemos adotar um monorepo?

Quando dois ou mais apps ou um pacote de UI compartilhado são lançados pela mesma equipe.
Equipes de um único app devem permanecer em um único repo até que a dor da duplicação seja mensurável.

Turborepo ou Nx para Expo?

Turborepo para caching mais simples e workspaces pnpm.
Nx quando você precisa de geradores, imposição de limites e grafos de affected em escala.

Vários apps Expo podem compartilhar um node_modules?

Sim, na raiz do workspace com pnpm - cada app ainda precisa de seu próprio app.config e projeto EAS.
O Metro deve resolver uma única instância de react-native.

Relacionado

Noções Básicas de Configuração de Projeto - layout, scripts e verificação da primeira execução
Templates create-expo-app - escolhendo o starter certo
Estrutura de Pastas para Features - fatias de feature vs camadas
Monorepo com Turborepo - pacotes compartilhados e caching
Pacotes Compartilhados e Resolução do Metro - watchFolders e symlinks
Múltiplos Apps em um Repo - padrões de white-label

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).

Melhores Práticas de Configuração de Projeto

Um resumo condensado das 25 melhores práticas mais importantes, extraídas de todas as páginas desta seção.

Scaffold com um pin de template do SDK: npx create-expo-app@latest --template default@sdk-57 - atualizar mais tarde custa mais do que começar no SDK suportado.
Execute expo-doctor no primeiro dia: Corrija o descompasso de versão antes do primeiro PR de feature - doctor pega incompatibilidades de configuração e dependências cedo.
Commite os lockfiles com o app: CI e EAS devem resolver a mesma árvore que o desenvolvimento local - instalações flutuantes escondem o descompasso nativo/JS até o TestFlight.
Mantenha os scripts do package.json simples: start, ios, android, lint, typecheck - cada engenheiro não deve memorizar flags do Metro pontuais.
Estenda expo/tsconfig.base: TypeScript rigoroso do template - desvios customizados no tsconfig quebram rotas tipadas do Expo Router e tipos de autolinking.
Use app.config.ts para ambientes: Configuração dinâmica supera arquivos app.json duplicados - controle variantes com variáveis de ambiente APP_VARIANT ou BRAND.
Escolha o menor template que se encaixe: blank-typescript para aprendizado; tabs apenas quando a navegação é escopo do primeiro dia - delete boilerplate não utilizado imediatamente.
Organize por feature, não apenas por camada: features/orders/ possui telas, hooks e apresentadores - components/ global é apenas para primitivas do design system.
Uma exportação pública por feature: Arquivos de rota importam OrdersScreen de features/orders - sem imports profundos entre features em hooks/useOrder.ts.
Diretório app/ enxuto: Arquivos do Expo Router re-exportam telas de features - a lógica de negócios não vive ao lado de _layout.tsx.
Comece monorepos com pnpm + Turborepo ao compartilhar UI: apps/mobile + packages/ui com workspace:* - adicione Nx quando geradores e grafos de affected justificarem a complexidade.
Deixe o SDK 57 configurar o Metro primeiro: Detecção automática de monorepo supera watchFolders escritos manualmente - personalize apenas quando doctor e builds provarem uma lacuna.
Faça hoist ou isole os symlinks do pnpm conscientemente: nodeLinker: hoisted evita muitos bugs de symlink do Metro - documente a escolha no README para onboarding.
Nunca duplique react-native no grafo: Duas cópias nativas causam "Invalid hook call" e obscurecem redboxes - npx expo-doctor e verificações de why react-native em CI.
Declare peerDependencies em pacotes compartilhados: Bibliotecas de workspace devem ter react, react-native e expo como peerDependencies - os apps fornecem a única versão instalada.
Use tags Nx para limites: scope:orders não pode importar internos de scope:billing - imponha com @nx/enforce-module-boundaries em organizações em crescimento.
Execute tarefas afetadas em CI: nx affected -t lint,typecheck,test mantém PRs de monorepo rápidos - execuções de repositório completo não escalam além de uma dúzia de pacotes.
White-label com configuração, não forks: apps/acme e apps/globex compartilham packages/core - tokens de marca são injetados via BrandProvider, não copiando e colando telas.
Separe o projectId do EAS por binário do app: Flavors de white-label precisam de credenciais, variáveis de ambiente e canais de atualização distintos - um projectId por bundle ID.
Gitignore pastas nativas sob CNG: ios//android/ commitados bloqueiam upgrades de SDK - regenere em EAS Build ou expo prebuild --clean.
Documente a verificação da primeira execução: Um script que executa expo-doctor, tsc --noEmit e um build de cliente de desenvolvimento - novos contratados provam a toolchain em um comando.
Ignore .env.local, commite .env.example: Segredos específicos da máquina permanecem locais - o env de exemplo documenta as chaves EXPO_PUBLIC_* necessárias sem valores.
Alinhe Babel e Metro com o template: Plugins customizados pertencem à configuração documentada - desvios silenciosos do Babel quebram Fast Refresh e Reanimated.
Escolha Turborepo ou Nx, não ambos os orquestradores: Um único dono do grafo de tarefas - misturar confunde scripts dev e chaves de cache.
Revise a estrutura de pastas com ~15 engenheiros: Layouts apenas por camada colapsam sob equipes de feature paralelas - agende uma migração antes que ciclos de import forcem uma reescrita.

FAQs

Quando devemos adotar um monorepo?

Quando dois ou mais apps ou um pacote de UI compartilhado são lançados pela mesma equipe.
Equipes de um único app devem permanecer em um único repo até que a dor da duplicação seja mensurável.

Turborepo ou Nx para Expo?

Turborepo para caching mais simples e workspaces pnpm.
Nx quando você precisa de geradores, imposição de limites e grafos de affected em escala.

Vários apps Expo podem compartilhar um node_modules?

Sim, na raiz do workspace com pnpm - cada app ainda precisa de seu próprio app.config e projeto EAS.
O Metro deve resolver uma única instância de react-native.

Relacionado

Noções Básicas de Configuração de Projeto - layout, scripts e verificação da primeira execução
Templates create-expo-app - escolhendo o starter certo
Estrutura de Pastas para Features - fatias de feature vs camadas
Monorepo com Turborepo - pacotes compartilhados e caching
Pacotes Compartilhados e Resolução do Metro - watchFolders e symlinks
Múltiplos Apps em um Repo - padrões de white-label

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).

Melhores Práticas de Configuração de Projeto

FAQs

Relacionado

Buscar na documentação

Melhores Práticas de Configuração de Projeto

FAQs

Relacionado