A Key Rspack Plugin Now Requires Modern JavaScript

The popular eslint-rspack-plugin has a major update that drops support for older code, potentially slowing down developer build times.

A significant update to a key developer tool in the Rspack ecosystem has been released, introducing a breaking change that teams will need to address. According to reporting by InfoQ, version 5.0.0 of the eslint-rspack-plugin is now available as a pure ECMAScript Module (ESM) package. This modernization effort completely removes the older CommonJS build, a move designed to align the plugin with the forward-looking standards of the Rspack build tool itself. The plugin, which integrates ESLint for code quality analysis directly into the build process, is a popular choice for developers using the high-performance, Rust-based bundler. While the update brings consistency to the ecosystem, its nature as a breaking change means developers cannot simply upgrade without potential modifications to their project configurations and a careful review of its performance implications.

The core technical shift is the move to being a "pure ESM" package. For years, the JavaScript world has been transitioning away from the older CommonJS standard, recognizable by its `require()` syntax, toward the more modern and standardized ECMAScript Modules, which use `import` and `export` statements. ESM offers benefits like better static analysis and tree-shaking, which can lead to smaller final code bundles. By making this plugin pure ESM, its maintainers are enforcing modern standards and ensuring compatibility with an ecosystem that is itself built on modern principles. This means any project using this new version must also be configured to properly handle ESM packages, a change that can sometimes have cascading effects throughout a project's dependency tree and build configuration, requiring a deliberate migration effort from development teams.

This update directly affects developers, DevOps engineers, and CTOs who have adopted Rspack as a faster alternative to older tools like Webpack. The primary trade-off presented by this plugin is convenience versus performance. Integrating ESLint directly into the build process is convenient, as it ensures all code is checked for quality and style issues before it is bundled. However, this convenience can come at a cost, as running these checks adds overhead and can increase build times. The release notes explicitly advise users to consider this impact. For a small project, the delay might be negligible, but for large enterprise-scale applications, even small increases in build time can disrupt developer workflows and slow down continuous integration pipelines. This forces a strategic decision: is the convenience of integrated linting worth a potential performance hit?

The broader industry context for this change is the ongoing, albeit slow, migration of the entire JavaScript ecosystem to ESM. This move by a plugin for a next-generation build tool is a strong signal that the momentum is accelerating. For business leaders and CTOs, this reinforces the importance of investing in modern toolchains and keeping development practices current. The most practical takeaway from this release is the advice to decouple processes. Instead of bundling code quality checks with the build step, teams are encouraged to run linting as a separate command. This can be automated using Git hooks (which run checks before code is committed) or as a distinct step in a CI/CD pipeline. This separation of concerns allows the build process to remain as fast as possible, providing quick feedback on bundling, while still enforcing code quality standards without becoming a bottleneck.