The eslint-rspack-plugin released version 5.0.0 as a pure ESM package, removing support for CommonJS. This shift aligns the plugin with the broader Rspack ecosystem, requiring developers to use ECMAScript Modules (ESM) for configuration and integration to maintain compatibility with the high-performance build tool.
The transition to a pure ESM (ECMAScript Modules) architecture marks a definitive break from CommonJS, the legacy module system used in Node.js. For developers, this means the plugin can no longer be loaded using require()
statements; instead, it requires the import
syntax. While this change introduces a breaking update for existing projects, it removes the technical overhead of supporting two disparate module systems.
The Technical Shift to Pure ESM
ESM is the official standard for packaging JavaScript code for both browsers and servers. By shipping version 5.0.0 as a pure ESM package, the eslint-rspack-plugin eliminates the dual-package hazard,
a common issue where a library provides both CommonJS and ESM versions, often leading to bugs and increased bundle sizes. This move simplifies the codebase and ensures that the plugin operates natively within the modern JavaScript environment.
This development is not an isolated choice but a strategic alignment with Rspack. Rspack, a high-performance web bundler written in Rust, is designed for speed and modern standards. Because Rspack’s internal architecture leans heavily toward ESM, the plugin’s update ensures that the linting process does not become a bottleneck or a source of compatibility errors during the build cycle.
The practical result is a streamlined dependency graph. When a tool is “pure ESM,it signals to the Node.js runtime that it should be treated as a module, allowing for better static analysis and more efficient
tree-shaking”—the process of removing unused code from the final bundle.
Impact on Rspack Configuration Files
Developers upgrading to version 5.0.0 will encounter immediate errors if their configuration files still rely on CommonJS. To resolve this, the package.json of the project must include “type”: “module”
, or the configuration file extension must be changed from .js to .mjs.
This requirement creates a ripple effect across the development environment. Since the eslint-rspack-plugin is used to integrate ESLint—a tool for identifying problematic patterns in JavaScript code—into the Rspack build process, the entire linting pipeline must now be ESM-compatible. If a project uses a complex set of custom ESLint rules or plugins that are still strictly CommonJS, developers may need to wrap those dependencies or update them to avoid runtime crashes.
The move essentially forces a modernization of the build pipeline. While the initial migration may require manual updates to configuration files, the long-term benefit is a build system that is more consistent with the way modern frontend frameworks and libraries are authored.
Aligning with the Rspack Ecosystem
The decision to drop CommonJS support is a reflection of the broader goals of the Rspack project. By prioritizing ESM, the ecosystem reduces the friction between the Rust-based core of the bundler and the JavaScript-based plugins that extend its functionality.
This alignment means that the eslint-rspack-plugin can more effectively leverage the performance gains promised by Rspack. In a mixed-module environment, the runtime often has to perform expensive conversions or maintain separate state for different module types. By standardizing on ESM, the plugin minimizes this overhead, contributing to the faster cold-start and hot-reload times that define the Rspack experience.
For the end user, this means the linting phase of a build is less likely to be the “slow point” in the development loop. When the bundler and the plugin speak the same module language, the integration is tighter and the execution is more predictable.
Whether this transition will prompt other Rspack-related plugins to similarly drop CommonJS support remains to be seen, but version 5.0.0 sets a clear precedent for the direction of the toolchain.
