Você realmente precisa de languageOptions.globals no seu ESLint quando usa TypeScript?

Muita gente ainda se pergunta se é necessário configurar globals no ESLint ao trabalhar com TypeScript. No fundo, a maioria dos desenvolvedores acha que o TypeScript já cobre tudo, mas será que é bem assim?

---

O papel do TypeScript

TypeScript faz uma verificação bem completa do tipo e das definições, então muitas configurações do ESLint acabam ficando redundantes. Mas, ao mesmo tempo, o ESLint serve pra pegar coisas que o TypeScript não consegue, como regras específicas de código, estilos ou globals que não são capturados pelas definições.

---

Globals no ESLint

Se você usa globals no ESLint, está basicamente informando ao linter que certas variáveis são conhecidas de antemão, evitando erros de variáveis não definidas ou de escopos específicos.

Porém, se essas variáveis são realmente globais do seu projeto ou do ambiente (como no navegador ou Node), faz sentido definir isso na configuração. Mas se você tá só querendo evitar warnings do ESLint por causa de variáveis que TypeScript já conhece, talvez seja redundante. 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.

---

Então, pra que serve?

No meu ponto de vista, a configuração de globals deve ser usada com moderação. Se o seu projeto tem variáveis globais específicas que o TypeScript não captura, beleza, configure. Caso contrário, melhor deixar o ESLint confiar na integração com o TypeScript e evitar configurações à toa. 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.

E vocês, já tiveram dor de cabeça com isso? Como equilibram essa configuração?

---

Pergunta final: Vocês acham que vale a pena manter esses globals no ESLint ou é melhor confiar na integração com o TypeScript e evitar redundâncias? 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. 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. A decisão fica mais saudável quando o time consegue medir o impacto depois.