# ADR-0002 — Substituir `eslint-config-standard` por `neostandard`

- **Status**: aceita
- **Data**: 2026-08-02
- **Decisores**: ThaSMorato

## Contexto

Os três presets estendiam `eslint-config-standard@17.1.0`, que é a base da maior parte das regras
que o pacote entrega hoje. Esse config:

- está travado em 17.1.0, sem release desde 2023;
- existe **apenas em formato eslintrc** — nunca portou para flat config;
- por isso é incompatível com a decisão da [ADR-0001](0001-target-eslint-9-flat-config.md).

As saídas eram: (a) manter o standard via `FlatCompat`, (b) trocar por `neostandard`, ou
(c) abandonar a linhagem standard e montar a base do zero com `typescript-eslint`.

## Decisão

Usar `neostandard@^0.13.0` com `{ noStyle: true, ts: true }`.

`FlatCompat` foi descartado porque manteria uma dependência abandonada no caminho crítico e
adicionaria uma camada de tradução que quebra a cada mudança de schema do ESLint. Montar do zero
foi descartado porque perderia de graça um conjunto de regras que o pedido original pedia para
preservar ("manter o máximo dos lints que ele faz").

`noStyle: true` desliga as regras de formatação do `@stylistic` embutido, porque a formatação
continua sendo do Prettier — ver [ADR-0004](0004-prettier-acoplado.md).

## Consequências

**Positivas**
- Sucessor mantido e explicitamente desenhado como continuação do standardjs.
- Flat config nativo, sem camada de compatibilidade.
- Traz `n`, `promise`, `react` e `@typescript-eslint` já registrados.

**Negativas**
- Versão `0.x`: o semver permite breaking change em minor. Fixar com `^0.13.0` limita, mas o
  acompanhamento tem que ser manual.
- **`neostandard` empacota o próprio `eslint-plugin-n@17`.** Registrar `eslint-plugin-n@18` no
  topo cria duas instâncias e o flat config lança `Cannot redefine plugin "n"`. Reproduzido
  durante a implementação. Por isso `eslint-plugin-n` e `eslint-plugin-promise` **foram removidos
  das dependências** — quem os registra é o neostandard, e os presets apenas adicionam regras
  com o prefixo `n/`.

## Nota de implementação

`react` e `@typescript-eslint` não colidem: o npm faz hoisting e as instâncias acabam sendo as
mesmas que `eslint-plugin-react` e `typescript-eslint` resolvem. Isso é verdade por acaso da
resolução, não por contrato. Se um dia colidir, o sintoma será o mesmo `Cannot redefine plugin`
e a saída é a mesma adotada para o `n`: parar de registrar e só adicionar regras.