# ADR-0003 — Trocar `eslint-plugin-import` por `eslint-plugin-import-x`, sem as regras de resolução

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

## Contexto

O config usava `eslint-plugin-import@2.29` para exatamente três regras: `import/first`,
`import/newline-after-import` e `import/no-duplicates`.

`eslint-plugin-import@2.32.0` declara peer `eslint` até `^9` e tem cadência de release lenta —
é mais um bloqueador para o ESLint 10 ([ADR-0001](0001-target-eslint-9-flat-config.md)).
`eslint-plugin-import-x@4.17.1` é o fork mantido, declara `^8.57 || ^9 || ^10` e expõe
`flatConfigs` nativo.

## Decisão

1. Trocar por `eslint-plugin-import-x@^4.17.1`, com as mesmas três regras sob o prefixo `import-x/`.
2. **Não** espalhar `importX.flatConfigs.recommended` nem `.typescript`.
3. Registrar um resolver explícito via `createNodeResolver()`.

## Por que não o `recommended`

A tentação era usar o preset pronto. Ao lintar o próprio repositório com ele, todo arquivo
reportou:

```
Resolve error: typescript with invalid interface loaded as resolver   import-x/no-unresolved
```

O `flatConfigs.typescript` exige `eslint-import-resolver-typescript`, que não estava instalado —
e isso teria quebrado **todos os consumidores**, não só este repositório. Mesmo com o resolver
instalado, `import-x/no-unresolved` gera falso-positivo com path alias de TypeScript, que é
justamente o cenário dos projetos que consomem este config.

Além disso a regra é redundante: o `tsc` já reporta import que não resolve, com mensagem melhor.

Manter só as três regras de higiene também devolve o config à intenção original — o preset
`recommended` era escopo que eu ampliei sem o pedido pedir.

## O resolver ainda é necessário

Mesmo sem as regras de resolução, `import-x/no-duplicates` percorre os imports e precisa de um
resolver. O `import-x` v4 **não traz um default válido**; sem configuração explícita o erro é:

```
Resolve error: node with invalid interface loaded as resolver   import-x/no-duplicates
```

Daí `settings: { 'import-x/resolver-next': [createNodeResolver()] }` no config base.

## Consequências

**Positivas**
- Um bloqueador a menos para o ESLint 10.
- Plugin com manutenção ativa.
- Sem dependência de resolver de TypeScript e sem falso-positivo com path alias.

**Negativas**
- Prefixo de regra muda de `import/` para `import-x/`. Qualquer `eslint-disable-next-line
  import/...` nos projetos consumidores precisa ser reescrito.
- Sem `no-unresolved`, um import quebrado em projeto JS puro só aparece em runtime.

## Como isso foi encontrado

Nenhum dos dois defeitos apareceu na suíte de testes — os testes afirmavam sobre `ruleId`, e um
erro de resolução aparece no **texto** da mensagem. Quem pegou foi lintar o próprio repositório
com o config publicado. Ficaram os dois: o dogfood virou o script `lint`, e há um teste de
regressão que falha se qualquer mensagem contiver `Resolve error`.