Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Manter arquivos de configuração do Next.js em TypeScript, como o 'next.config.ts', traz um dilema de compatibilidade e custo operacional.
Quando usamos 'next.config.js', recebemos um aviso no tsconfig.json indicando que o arquivo 'next.config.ts' não foi encontrado, o que causa preocupação na equipe sobre a consistência do projeto. Por outro lado, alterar para '.ts' gera o erro explícito de que essa configuração não é suportada pelo Next.js.
Essa situação aumenta o esforço de manutenção, pois temos que decidir entre ignorar warnings ou lidar com erros que interrompem o build. Além do impacto na produtividade, isso pode gerar dúvidas na equipe e aumentar o risco de configurações quebradas ao longo do tempo.
Na minha opinião, essa incompatibilidade reflete uma limitação de suporte oficial, obrigando a equipe a trabalhar com hacks ou configurações alternativas, o que dá trabalho depois e dificulta a escalabilidade do projeto. O valor aparece melhor quando operação, produto e engenharia olham para o mesmo risco. Por isso, o recorte precisa considerar manutenção, validação e caminho de volta.
O que vocês fazem nos seus times para lidar com esse tipo de problema de compatibilidade entre ferramentas e configuração de build? Será que vale a pena investir em uma camada de abstração que minimize esses custos? Por isso, o recorte precisa considerar manutenção, validação e caminho de volta. Esse contexto ajuda a separar ganho real de novidade difícil de sustentar. A decisão fica mais saudável quando o time consegue medir o impacto depois. Sem esse critério, a solução pode parecer simples no começo e cara no suporte.
Pô, na moral, isso dá um trabalho depois. Já passei por essa dor de ter que manter configs diferentes só pra ev itar erro. Minha dica é usar o JS padrão e documentar bem as configurações, assim fica mais fácil pra equipe.
No meu time, a gente prefere usar o 'next.config.js' padrão mesmo e ignora os warnings. Não vejo benefício em arriscar usar TS direto ali, pq o suporte oficial é bem limitado. Melhor manter simples e evitar dor de cabeça.
Isso me pega em questão de acessibilidade na UI. Se o arquivo de config gerar warnings constantes, fica difícil focar na experiência do usuário.
Concordo, mas acho que o maior peso é na hora do build e deploy. Se a lib ou framework não suporta TS pra config, acaba complicando a automação. Nesse caso, acho que o custo de tentar forçar o suporte é maior que o benefício.