Compartilhamento de Camada de Domínio TypeScript em Monorepos Next.js e Expo Otimiza Desenvolvimento

A adoção de uma camada de domínio compartilhada em TypeScript, unificando projetos Next.js e Expo, é uma estratégia potente para desenvolvedores que buscam consistência e eficiência em monorepos. Essa abordagem foca em compartilhar artefatos que não dependem da plataforma, como tipos de dados, esquemas de validação (com bibliotecas como Zod ou Valibot) e um cliente API 'thin'. O objetivo é garantir que tanto o lado web quanto o mobile consumam as mesmas definições, evitando a duplicação de código e minimizando a chance de desalinhamento de contrato com o backend. Como exploramos em março de 2026 na matéria “Como resolver o desalinhamento entre tipos React e APIs com OpenAPI”, a abordagem contract-first, com geração automática de tipos a partir de uma fonte única de verdade como OpenAPI, já apontava para essa necessidade de sincronização rigorosa entre frontend e backend. A camada de domínio compartilhada estende essa filosofia para os próprios aplicativos, garantindo que as definições de dados e a validação sejam as mesmas em todos os pontos de contato da arquitetura.

É crucial manter um limite claro para o que é compartilhado. Lógicas de UI, navegação e armazenamento específicas de cada plataforma (como cookies no navegador ou `expo-secure-store` no mobile) devem permanecer isoladas. A regra de ouro é: se o tipo de retorno de uma função depende do ambiente (navegador ou dispositivo), ela deve ficar no aplicativo. Se a dependência é apenas dos dados, a função pode ir para o pacote compartilhado. Isso permite que a arquitetura do monorepo se beneficie da tipagem forte do TypeScript e da validação consistente de dados, sem introduzir complexidade desnecessária ou acoplamento entre as plataformas.

Historicamente, a resolução de pacotes em monorepos com pnpm e Metro (o empacotador do Expo) apresentava desafios devido à forma como pnpm utiliza symlinks. Metro, por padrão, resolvia módulos andando por caminhos de arquivo reais, não seguindo os links simbólicos do pnpm. Isso levava a erros de resolução ou, pior, a versões incorretas de dependências, exigindo gambiarras como `unstable_enableSymlinks` ou forçar o `node-linker=hoisted` do pnpm. Com o lançamento do Expo SDK 54, essa situação mudou significativamente. O `expo/metro-config` agora traz suporte nativo a monorepos, incluindo o reconhecimento de symlinks do pnpm. Isso elimina a necessidade de configurações manuais complexas como `watchFolders` ou `resolver.nodeModulesPaths`, simplificando bastante a experiência do desenvolvedor. Essa evolução se alinha ao foco contínuo do Expo na otimização da experiência do desenvolvedor, como vimos com o Expo Modules 2.0 em setembro de 2026, que também buscou aprimorar a arquitetura para desenvolvedores nativos.

Esta estratégia é vital porque estabelece uma base sólida para a construção de aplicações robustas e de fácil manutenção em monorepos. Ao centralizar tipos e validações, a chance de erros decorrentes de inconsistências na API é drasticamente reduzida, pois qualquer alteração no backend que quebre o contrato será detectada em tempo de desenvolvimento em ambas as plataformas. Isso melhora a qualidade do software e a produtividade da equipe, permitindo que os desenvolvedores foquem na lógica de negócio e na experiência do usuário, em vez de lidar com bugs de tipagem ou validação em diferentes ambientes. A otimização da resolução de pacotes pelo Expo SDK 54 é um passo importante para tornar a gestão de dependências em monorepos mais fluida, removendo barreiras técnicas que antes dificultavam a adoção de boas práticas arquiteturais.