eslint-rspack-plugin 5.0: A Leap Toward Inclusive Build Practices

Introduction: A New Era for ESLint in Rspack

The JavaScript ecosystem is in constant flux, and staying current is not just about adopting new features—it's about embracing practices that make development more inclusive and efficient for all contributors. The recent release of eslint-rspack-plugin version 5.0.0 marks a significant step in this direction. By transitioning to a pure ESM package, this plugin not only aligns with the broader Rstack ecosystem but also sets a precedent for how modern tooling can reduce friction and welcome a wider range of developers.

Understanding the Shift to Pure ESM

In version 5.0.0, eslint-rspack-plugin has removed its CommonJS build, becoming a pure ESM package. This move mirrors Rspack 2.0's own transition, which also deprecated CommonJS in favor of ESM. The rationale behind this shift is to ensure consistent module loading across the ecosystem and to align with current Node.js conventions. For most projects, this change is seamless, thanks to Node.js 20+ supporting require(esm), allowing CommonJS projects to load ESM modules without code changes. This reduces the cognitive load on developers who might otherwise need to juggle different module systems, fostering a more inclusive environment where contributors can focus on writing code rather than wrestling with configuration.

What Does This Mean for Developers?

For developers using the plugin through JavaScript APIs, the impact is minimal. The plugin's functionality remains intact: it runs ESLint during the Rspack build process, and in watch mode, it only re-lints files that have been modified. This targeted approach saves time and resources, which is especially beneficial in large projects. The plugin was originally forked from eslint-webpack-plugin, so webpack users will find the configuration interface familiar. A typical setup involves registering the plugin in the Rspack configuration file, a process that remains unchanged.

Key Features in the 5.x Series

The 5.x series introduces several options that enhance flexibility and performance:

• Enabled by Default: The plugin works out of the box, reducing setup time and making it accessible to beginners.
• Caching: A cache option shortens execution time by storing results, which is a boon for iterative development.
• configType: This switch allows developers to choose between the classic eslintrc format and ESLint's newer flat config, catering to different preferences and migration stages.
• Threads: For CPU-intensive linting, the threads option runs tasks in a thread pool, improving concurrency and speed.
• lintAllFiles: This option lints all matching files, not just those in the dependency graph. It's particularly useful for multi-environment builds like Rsbuild and Rspack, where separate client and server checks might miss files.

The Performance Debate: To Lint or Not to Lint in Build

While the plugin is powerful, the project's README offers a thought-provoking reminder: "Not using eslint-rspack-plugin may be more efficient, because running ESLint during the build process can increase build time." This advice is echoed in @rsbuild/plugin-eslint and the Rsbuild FAQ, which states that Rsbuild does not run ESLint by default to "guarantee compilation performance." This highlights a broader industry shift: separating linting from the build process can lead to faster builds and a more streamlined developer experience. For teams prioritizing speed, running a standalone linter—whether via a dedicated script or a faster alternative like Rslint—might be more advantageous than integrating linting into the bundler.

Embracing Inclusion Through Tooling Choices

This shift toward performance-oriented tooling is not just about speed; it's about inclusivity. By reducing build times, we lower the barrier for contributors who may have less powerful hardware or slower internet connections. Faster feedback loops mean that developers can iterate more quickly, making the development process more accessible and enjoyable for everyone. Moreover, the move to pure ESM simplifies module resolution, which can be particularly confusing for newcomers. By standardizing on ESM, the ecosystem becomes more predictable, reducing the learning curve and making it easier for diverse contributors to get involved.

Rslint: A Glimpse into the Future

The Rstack team has also released Rslint, a TypeScript-first, ESLint-compatible linter written in Go, based on typescript-go. Rslint claims to be 20 to 40 times faster than traditional ESLint configurations. This is a game-changer for teams that value build speed. By offering a standalone, ultra-fast linter, Rslint provides an alternative that can be run independently of the build process, further decoupling linting from compilation. This not only speeds up builds but also allows for more flexible CI/CD pipelines, where linting can be parallelized or run on demand, making the development workflow more adaptable and inclusive of various project structures.

Upgrade Path and Best Practices

For developers upgrading from the 4.x series, it is essential to test the pure ESM changes against their toolchain. Additionally, adopting ESLint's flat config via configType: 'flat' is recommended, as it aligns with ESLint's future direction and simplifies configuration. The Rspack 2.0 release notes provide detailed guidance on the underlying ESM migration. By staying current with these changes, developers can ensure their projects remain compatible and benefit from the latest performance improvements.

Conclusion: A Step Toward a More Inclusive Ecosystem

The release of eslint-rspack-plugin 5.0.0 is more than a version bump; it's a statement about the direction of modern web development. By embracing pure ESM and encouraging performance-conscious linting practices, the Rstack ecosystem is paving the way for a more inclusive and efficient development environment. Whether you choose to integrate linting into your build or opt for a standalone tool, the goal is to create a smoother, more accessible experience for all developers. As we move forward, it's clear that thoughtful tooling decisions can have a profound impact on community participation and project sustainability.

References and Further Reading

For more details, check the official eslint-rspack-plugin documentation, the Rspack 2.0 release notes, and the Rsbuild FAQ. The plugin is open-sourced under the MIT license and is available on npm. As you explore these resources, consider how your own tooling choices can contribute to a more inclusive development culture.