O eslint-rspack-plugin 5.0.0 chega como pacote ESM puro e realinha o ecossistema Rstack

O eslint-rspack-plugin, plugin que roda checagens do ESLint durante a compilação com Rspack, lançou a versão 5.0.0 publicada como pacote ESM puro, com o build CommonJS removido. A mudança realinha a ferramenta com o ecossistema Rstack mais amplo.

O que muda na 5.0.0

Segundo a InfoQ, a principal alteração é justamente o formato de distribuição: agora é ESM puro, sem CJS. O movimento espelha o Rspack 2.0, que republicou seus pacotes centrais como ESM puro e derrubou os builds CommonJS para tornar o carregamento de módulos mais consistente e alinhado às práticas atuais do Node.js.

A boa notícia para quem já roda em produção: como o Node.js 20 e versões posteriores já conseguem carregar módulos ESM via require(esm), a maioria dos projetos que consomem o plugin pela API JavaScript deve ver pouco impacto prático e não precisa de mudanças no código.

Funcionalmente, o plugin continua rodando o ESLint como parte do build e, em modo watch, reexecuta o ESLint apenas nos arquivos que o Rspack alterou. Ele foi originalmente derivado do eslint-webpack-plugin, então a superfície de configuração é familiar para quem vem do webpack.

Opções que seguem na linha 5.x

A reportagem lista as opções mantidas na versão nova:

• cache: ligado por padrão, para reduzir tempo de execução;
• configType: alterna entre o formato clássico eslintrc e o novo flat config do ESLint;
• threads: distribui tarefas de lint em um pool de threads;
• lintAllFiles: analisa todos os arquivos correspondentes, e não só os presentes no grafo de dependências. Essa opção mira builds multi-ambiente de Rsbuild e Rspack, onde passagens separadas de cliente e servidor poderiam deixar arquivos de fora.

O aviso sobre performance de build

Um ponto que a fonte destaca: o próprio README do projeto recomenda cautela. Rodar o ESLint durante o build pode aumentar o tempo de compilação, e a orientação é considerar um comando de lint separado. A mesma recomendação aparece no @rsbuild/plugin-eslint (que embrulha o plugin internamente) e no FAQ do Rsbuild, que por padrão não roda ESLint durante builds "para proteger a performance de compilação".

Esse cuidado reflete uma tendência mais ampla. O time do Rstack agora oferece o Rslint, um linter TypeScript-first compatível com ESLint, escrito em Go e baseado no typescript-go, que segundo a InfoQ afirma entregar linting de 20 a 40 vezes mais rápido que setups tradicionais de ESLint. Para times atrás de velocidade de build, rodar um linter standalone rápido, seja ESLint via script dedicado ou uma alternativa como o Rslint, aparece cada vez mais como preferível a linkar dentro do próprio bundler.

O que isso muda para quem constrói software no Brasil

A migração para ESM puro em ferramentas de build e linting não é exclusividade desse plugin: é uma direção que ganha espaço no ecossistema JavaScript. Para equipes brasileiras que já adotaram Rspack ou Rsbuild em pipelines de front-end, vale registrar dois pontos práticos:

1. Testar a mudança para ESM puro contra sua toolchain antes de subir de versão. Quem está na linha 4.x deve validar a compatibilidade, especialmente em ambientes com Node mais antigo ou configurações mistas de CJS/ESM.
2. Adotar o flat config do ESLint via configType: 'flat' onde for viável, seguindo a recomendação da própria reportagem.

O contexto de migração do salto para ESM está documentado nas notas de lançamento do Rspack 2.0. O eslint-rspack-plugin é open source sob licença MIT e pode ser instalado pelo npm.

Para quem mantém projetos JS/TS em produção, a lição estrutural é a mesma além do plugin específico: o ecossistema está consolidando ESM como padrão, e separar o passo de lint do passo de bundle tende a ser a escolha mais saudável para tempos de build.

Fonte: InfoQ