Lint, formatação e tipos estritos.

Código que funciona é o mínimo. Código que funciona, é legível, e segue convenções consistentes é o que permite que equipes colaborem sem atritos. ESLint detecta padrões problemáticos antes de você executar o código. Prettier e Biome garantem que todo o código tem a mesma aparência, independentemente de quem escreveu. TypeScript em modo estrito fecha as brechas que o compilador deixa abertas por padrão.

ESLint analisa o código em busca de padrões que causam bugs ou problemas de manutenção — sem executar o código. Para um projeto React com TypeScript:

npm install -D eslint @eslint/js typescript-eslint eslint-plugin-react-hooks

import js from "@eslint/js";
import tseslint from "typescript-eslint";
import reactHooks from "eslint-plugin-react-hooks";

export default tseslint.config(
  js.configs.recommended,
  ...tseslint.configs.recommended,
  {
    plugins: {
      "react-hooks": reactHooks,
    },
    rules: {
      ...reactHooks.configs.recommended.rules,
      // erros frequentes em React + TS
      "@typescript-eslint/no-unused-vars": "error",
      "@typescript-eslint/no-explicit-any": "warn",
      "react-hooks/rules-of-hooks": "error",
      "react-hooks/exhaustive-deps": "warn",
    },
  }
);

Regras que valem a pena ativar:

• react-hooks/rules-of-hooks — detecta hooks chamados em condicionais ou loops
• react-hooks/exhaustive-deps — avisa quando dependências do useEffect estão faltando
• @typescript-eslint/no-unused-vars — variáveis declaradas mas não usadas
• @typescript-eslint/no-explicit-any — uso de any que anula a tipagem

npx eslint src/              # verificar a pasta src
npx eslint src/ --fix        # corrigir automaticamente o que for possível

Prettier reformata o código automaticamente — sem discussões de estilo no code review. Aspas simples ou duplas? Ponto-e-vírgula ou não? Vírgula no fim de objetos? Prettier decide e aplica para todos:

npm install -D prettier

{
  "semi": true,
  "singleQuote": false,
  "trailingComma": "es5",
  "printWidth": 100,
  "tabWidth": 2
}

npx prettier src/ --write      # formatar e salvar
npx prettier src/ --check      # verificar sem modificar (para CI)

Integração com ESLint: ESLint e Prettier podem conflitar — ESLint tem regras de estilo que Prettier pode desfazer. Use eslint-config-prettier para desativar as regras de estilo do ESLint que conflitam com Prettier:

npm install -D eslint-config-prettier

import prettier from "eslint-config-prettier";

export default tseslint.config(
  // ... outras configs
  prettier, // deve ser o último — desativa regras que conflitam
);

Biome é escrito em Rust e é 10–100× mais rápido que ESLint + Prettier. Oferece lint e formatação em um único binário, com configuração mínima e sem o problema de conflitos entre as duas ferramentas:

npm install -D @biomejs/biome
npx @biomejs/biome init

{
  "$schema": "https://biomejs.dev/schemas/1.9.4/schema.json",
  "formatter": {
    "enabled": true,
    "indentStyle": "space",
    "indentWidth": 2,
    "lineWidth": 100
  },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true,
      "suspicious": {
        "noExplicitAny": "warn"
      }
    }
  },
  "javascript": {
    "formatter": {
      "quoteStyle": "double",
      "trailingCommas": "es5",
      "semicolons": "always"
    }
  }
}

npx @biomejs/biome check src/           # lint + format check
npx @biomejs/biome check src/ --write   # corrigir automaticamente

Quando escolher Biome: projetos novos onde você tem liberdade para escolher o tooling. Quando manter ESLint + Prettier: projetos existentes com plugins específicos do ESLint que o Biome ainda não suporta.

O TypeScript tem um modo “relaxado” e um modo estrito. strict: true ativa várias verificações adicionais:

{
  "compilerOptions": {
    "target": "ES2022",
    "lib": ["ES2022", "DOM", "DOM.Iterable"],
    "module": "ESNext",
    "moduleResolution": "bundler",
    "jsx": "react-jsx",

    // tipagem estrita
    "strict": true,              // ativa: noImplicitAny, strictNullChecks, e mais
    "noUnusedLocals": true,      // variáveis locais não usadas → erro
    "noUnusedParameters": true,  // parâmetros não usados → erro
    "noFallthroughCasesInSwitch": true, // switch sem break → erro

    // módulos
    "esModuleInterop": true,
    "allowImportingTsExtensions": true,
    "resolveJsonModule": true,
    "isolatedModules": true,

    // output
    "noEmit": true,              // Vite cuida do transpile — TS só verifica tipos
    "skipLibCheck": true
  },
  "include": ["src"]
}

O que strict: true ativa:

• noImplicitAny — parâmetros sem tipo explícito são um erro (não viram any silenciosamente)
• strictNullChecks — null e undefined precisam ser tratados explicitamente: artigo?.titulo em vez de artigo.titulo quando artigo pode ser null
• strictFunctionTypes — verificação de compatibilidade de tipos de função mais rigorosa
• strictPropertyInitialization — propriedades de classe precisam ser inicializadas

Em projetos existentes sem strict, ativar pode revelar dezenas de erros acumulados — o que é bom, mas pode ser avassalador. A estratégia: ativar flag por flag, começando por noImplicitAny.

No editor (VS Code): instale as extensões ESLint e Prettier. Adicione ao settings.json:

{
  "editor.formatOnSave": true,
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": "explicit"
  }
}

No CI: verificar que código que passa no PR não viola regras:

- name: Lint
  run: npx eslint src/

- name: Type check
  run: npx tsc --noEmit

- name: Format check
  run: npx prettier src/ --check

• ESLint detecta padrões problemáticos — hooks em condicionais, variáveis não usadas, any explícito. Plugins essenciais: react-hooks, @typescript-eslint.
• Prettier formata automaticamente — sem discussões de estilo. Use eslint-config-prettier para evitar conflitos.
• Biome faz os dois em um, escrito em Rust, muito mais rápido. Boa escolha para projetos novos.
• strict: true no tsconfig.json detecta mais erros: noImplicitAny, strictNullChecks, variáveis não usadas.
• Integre ao editor (formatar ao salvar) e ao CI (verificar em cada PR) — sem depender de cada pessoa ter configurado o editor corretamente.