Manutenção de configurações TypeScript em projetos Next.js pode custar caro

No universo Next.js, usar um arquivo de configuração em TypeScript, como 'next.config.ts', parece uma solução moderna e prática. Mas a realidade é que essa configuração traz mais dor de cabeça do que benefício.

Segundo o StackOverflow, o Next.js oficialmente não suporta a configuração via arquivo TS. Ao tentar usar 'next.config.ts', você se depara com um erro dizendo que essa não é uma prática suportada, obrigando a trocar para 'next.config.js'. Além disso, o tsconfig.json fica cheio de avisos, o que pode confundir a equipe e dificultar a manutenção.

O custo disso na rotina de desenvolvimento e manutenção é alto. Cada alteração que exige uma adaptação na configuração faz a equipe perder tempo, além de aumentar o risco de bugs ou configurações incorretas. Para times que buscam agilidade e estabilidade, esse tipo de setup é um tiro no pé. Sem esse critério, a solução pode parecer simples no começo e cara no suporte. O valor aparece melhor quando operação, produto e engenharia olham para o mesmo risco.

Minha sugestão é sempre usar o padrão suportado, ou seja, o arquivo em JavaScript mesmo. Assim, evita-se retrabalho e incertezas na hora de atualizar dependências ou migrar versões do Next.js. Configurar tudo em JavaScript ajuda a manter a estabilidade e a previsibilidade na operação. 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. Esse contexto ajuda a separar ganho real de novidade difícil de sustentar.

Quem aí já passou por essa situação e conseguiu alguma solução alternativa? Ou acha que vale o esforço de tentar algo mais avançado mesmo assim?