# ADR-0005 — O preset `next` é um fragmento, não um config completo

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

## Contexto

O preset `next` sempre foi pensado para ser usado junto com `next/core-web-vitals` — é o que o
README documentava já na v1.

No flat config, registrar o mesmo plugin em dois blocos lança:

```
ConfigError: Config "next": Key "plugins": Cannot redefine plugin "jsx-a11y".
```

`eslint-config-next@16` registra `react`, `react-hooks` e `jsx-a11y`. O preset `next` também
registrava `react-hooks` e `jsx-a11y`, e o `neostandard` (base de todos os presets) registrava
`react`.

## Como isso foi verificado

Importante, porque a primeira medição estava errada. Testar o preset a partir do repositório
contra um `eslint-config-next` instalado em **outra** árvore de `node_modules` produziu colisões
falsas em `react`, `react-hooks` e `@typescript-eslint` — cada árvore resolve a sua própria
instância do módulo, então tudo parecia colidir.

A medição válida foi `npm pack` do pacote e instalação do tarball num projeto consumidor real,
com `next`, `eslint` e o config numa **árvore única**. Resultado:

| Cenário | Antes | Depois |
|---|---|---|
| `node` | ✔ | ✔ |
| `react` | ✔ | ✔ |
| `next` sozinho | ✔ | ✖ (esperado) |
| `next` + `core-web-vitals` | ✖ colisão `jsx-a11y` | ✔ |

E o achado contraintuitivo: **`react-hooks` não colide, `jsx-a11y` colide** — mesmo com uma única
cópia de cada no `node_modules`, sem duplicata aninhada. A causa não é duplicação de pacote: é
que `jsxA11y.flatConfigs.recommended` embrulha o plugin num objeto diferente do que o
`eslint-config-next` registra, e o ESLint compara por **identidade de objeto**.

## Decisão

1. `base` usa `neostandard({ noJsx: true })`, então a base nunca registra `react`.
2. O preset `react` é o dono único do registro de `react`.
3. O preset `next` **não registra nenhum** de `react`, `react-hooks`, `jsx-a11y`. Só ajusta
   regras e adiciona `**/*.jsx` / `**/*.tsx` ao alvo, deixando o Next ser o dono.

Consequência aceita: `next` sozinho lança `Could not find plugin "jsx-a11y"`. Isso é o
comportamento correto — o preset nunca fez sentido sozinho, e falhar alto é melhor que lintar
silenciosamente sem as regras do Next.

## Consequências

**Positivas**
- A composição documentada funciona, verificada através de um tarball instalado.
- Um dono por plugin, o que elimina a classe inteira de erro.

**Negativas**
- `next` não é utilizável sozinho, e o erro que ele dá nesse caso não explica o motivo.
- A escolha entre "funciona sozinho" e "funciona composto" é excludente; escolhi composto por ser
  o caso real de uso.

## Nota de teste

A suíte cobre isso de duas formas, sem trazer o `next` para as devDependencies (o que custaria
uma instalação enorme):

- um **stub** que registra os três plugins, simulando o `core-web-vitals`, para exercitar a
  composição;
- uma asserção estrutural de que o preset `next` não registra nenhum dos três — é o contrato, e
  quebrá-lo é o que produz a colisão.