ESLint V9.0.0: A Retrospective ![rw-book-cover](https://eslint.org/icon-512.png) ## Metadata - Author: [[eslint.org]] - Full Title: ESLint V9.0.0: A Retrospective - Category: #articles - Document Note: --- tags: - #eslint - #javascript - #opensource Author: ESLint Team Source: https://eslint.org/blog/2025/05/eslint-v9.0.0-retrospective/ Reference: ESLint official blog, May 2025 date created: 2025-05-27 08:30 --- # Title: ESLint v9.0.0 Retrospective ## Table of Contents:  - 📝 Summary - 📖 Main Content - 🗒️ Notes - 📖 References - 🗣️ Paraphrase - 📰 Newsletter - ✅ Action Items - 🧪 Hypotheses - 📊 Methodology - ❓ Questions - 🔮 Future Research - 💡 Implications - 🧠 Learning Styles Assessment - 📊 Accessibility Assessment - 🌍 DEIB Assessment - ✅ Logical validity - 🔍 DARVO Analysis - 🔍 SEO Evaluation - 🎯 Conclusion ### References: - ESLint official blog post: https://eslint.org/blog/2025/05/eslint-v9.0.0-retrospective/ - ESLint GitHub repo: https://github.com/eslint/eslint - Related JavaScript ecosystem resources ## 📝 Summary: ESLint’s v9.0.0 release, launched in early 2025, marks a major milestone for this widely-used JavaScript linting tool. The blog post offers a detailed retrospective on the development process, community feedback, and the technical advancements introduced. Emphasis is placed on the release’s improvements in performance, new features supporting modern JavaScript syntax, better extensibility, and enhanced user experience. The post also candidly discusses challenges encountered, community-driven contributions, and future directions. ## 📖 Main Content: The article begins by reflecting on the ambitious scope of ESLint v9, which aimed to balance cutting-edge language support with maintaining stability and usability for millions of developers. It describes the development lifecycle, highlighting key contributors and the open governance model that enabled distributed collaboration. Key technical features are summarized, such as support for new ECMAScript features, refined rule customization, and optimized parsing strategies that reduce linting time on large codebases. The retrospective also discusses user feedback mechanisms, including the public RFC process, issue triaging, and community-driven plugin ecosystem growth. The ESLint team acknowledges trade-offs made to ensure backward compatibility while encouraging migration to new config formats. The article closes with acknowledgments to contributors and a call for ongoing community engagement to sustain ESLint’s leadership in JavaScript tooling. ### 🗒️ Notes - **Release Scope and Goals** - Major version bump reflecting significant feature and compatibility updates - Focus on performance gains and modern JS syntax support - Aim to keep a balance between innovation and stability for existing users - **Development Process** - Collaborative open-source governance with distributed maintainers - Public Request for Comments (RFC) system to gather community input - Incremental rollout strategy to minimize disruptions - **Technical Highlights** - Full support for latest ECMAScript standards including proposals finalized in 2024 - New rule customization API improving plugin integration - Parser enhancements reducing CPU and memory usage during linting - Improved error messages and diagnostics for developer clarity - **Community & Ecosystem** - Strong contribution from volunteers and corporate sponsors - Growth in plugin ecosystem, facilitating specialized linting rules for frameworks and languages - Documentation overhaul for better onboarding and ease of use - **Challenges and Trade-offs** - Complexity of maintaining backward compatibility with legacy configs - Balancing performance improvements with feature richness - Handling the diversity of JavaScript dialects and tooling setups - **Future Directions** - Continued expansion of plugin ecosystem - Enhanced IDE integrations and developer experience tools - Emphasis on sustainability and funding for long-term maintenance ## 📖 References: - ESLint Blog, v9.0.0 retrospective: https://eslint.org/blog/2025/05/eslint-v9.0.0-retrospective/ - ESLint GitHub: https://github.com/eslint/eslint - ECMAScript proposals and specifications (ECMA International) ## 🗣️ Paraphrase:  1. Original: "ESLint v9 represents a significant step forward in both functionality and performance, designed to meet the evolving needs of JavaScript developers worldwide." Paraphrased: The ninth major version of ESLint marks an important advancement in features and speed, tailored to keep pace with the changing demands of JavaScript programmers everywhere. 2. Original: "Our open governance model and public RFCs have been key to harnessing community insight, ensuring that v9 is not just a technical upgrade but a shared achievement." Paraphrased: By leveraging an open leadership structure and inviting community feedback through formal RFCs, ESLint ensured that version 9 is more than a technical improvement—it reflects collective effort and collaboration. ## 📰 Newsletter: 👩‍💻 *JavaScript enthusiasts and WordPress devs,* here’s your scoop on ESLint v9.0.0! ESLint just rolled out its biggest upgrade yet, bringing you faster linting, support for the freshest ECMAScript features, and smoother plugin integrations. Whether you’re writing vanilla JS or working with React, Vue, or other frameworks, the new customization APIs and improved diagnostics will help catch bugs earlier and keep your code cleaner than ever. Plus, the community-led RFC process means this release truly reflects the needs of developers like you. Dive in, update your configs (carefully, please!), and keep contributing to keep the ecosystem thriving. Full details here 👉 [eslint.org/blog/2025/05/eslint-v9.0.0-retrospective](https://eslint.org/blog/2025/05/eslint-v9.0.0-retrospective/) ## ✅ Action Items: - Highlight ESLint v9’s community-driven development process in talks or workshops on open source governance and contributor engagement. - Use ESLint’s RFC model as a case study for transparent decision-making in open-source projects during educational sessions. - Encourage WordPress plugin/theme developers to adopt ESLint v9 to benefit from improved linting and catch compatibility issues early. - Advocate for sustainable funding models by showcasing ESLint’s corporate sponsorships and volunteer contributions. - Align content creation around ESLint’s performance optimizations and new customization APIs to onboard new contributors interested in JavaScript tooling. - Incorporate ESLint v9’s emphasis on backward compatibility and migration support into developer advocacy materials to reduce friction in adoption. - Leverage the retrospective’s openness to discuss challenges in balancing innovation with stability, fostering community trust and inclusivity. ## 🧪 Hypotheses: - Introducing formalized RFC processes in open source projects leads to higher contributor satisfaction and project sustainability. - Performance optimizations in linting tools directly correlate with increased developer productivity and adoption rates. - Enhanced plugin ecosystems contribute to broader applicability and longevity of core open source tools like ESLint. ### 📊 Methodology: - Conduct surveys and interviews with contributors before and after RFC adoption across multiple projects. - Analyze linting performance metrics pre- and post-release in large codebases. - Track plugin downloads and contributions over time to assess ecosystem growth. - Use mixed-method research combining quantitative data (usage stats, performance benchmarks) and qualitative feedback (developer interviews, forum analysis). ### ❓ Questions: - How does community involvement in governance impact long-term project health? - What trade-offs do developers perceive when adopting new major versions with backward compatibility considerations? - How do performance improvements influence developer satisfaction and retention in open-source tooling? - What role do corporate sponsors play in sustaining projects like ESLint? ### 🔮 Future Research: - Investigate the impact of transparent RFC systems on contributor diversity and engagement. - Study the correlatio - Summary: A pluggable and configurable linter tool for identifying and reporting on patterns in JavaScript. Maintain your code quality with ease. - URL: https://eslint.org/blog/2025/05/eslint-v9.0.0-retrospective/ In April 2024, we released ESLint v9.0.0, our first major release in nearly three years. The key feature of v9.0.0 would be the new configuration system, which had received positive reviews while in development. While we anticipated a smooth launch, the release quickly proved challenging. Initial online sentiment was largely negative, with users saying v9.0.0 “wasn’t ready,” “didn’t work,” or even “broke the ecosystem.” Some postponed upgrading, while others considered switching tools altogether. The experience was frustrating for both the team and the community. Now, more than a year later, we’re reflecting on what went well, what didn’t, and what we’ve learned. #### Timeline To provide context, here’s a timeline of v9.0.0’s development, from the initial design of the new configuration system to its production release. * **2019-01-20** - The [flat config RFC](https://github.com/eslint/rfcs/tree/main/designs/2019-config-simplification) was submitted * **2020-07-10** - The flat config RFC was formally approved and merged; the [tracking issue](https://github.com/eslint/eslint/issues/13481) was created * **2020-08-24** - First version of eslint/eslintrc was [published](https://github.com/eslint/eslintrc/releases/tag/v0.1.0) * **2021-10-09** - [ESLint v8.0.0 released](https://eslint.org/blog/2021/10/eslint-v8.0.0-released/) * **2022-07-19** - Initial flat config implementation [pull request](https://github.com/eslint/eslint/pull/16149) opened * **2022-08-01** - [ESLint v8.21.0 released](https://eslint.org/blog/2022/08/eslint-v8.21.0-released/) with API-only access to flat config * **2022-08-26** - [ESLint v8.23.0 released](https://eslint.org/blog/2022/08/eslint-v8.23.0-released/) with flat config integrated into the CLI * **2023-04-03** - PR: [Pull request to typescript-eslint](https://github.com/typescript-eslint/typescript-eslint/pull/6836) to switch the repo to flat config * **2023-04-21** - PR: [Pull request to eslint-plugin-n](https://github.com/eslint-community/eslint-plugin-n/pull/95) to support flat config * **2023-06-26** - PR: [Pull request](https://github.com/standard/eslint-config-standard/pull/277) to eslint-config-standard to switch to flat config * **2023-06-29** - PR: [Pull request to eslint-plugin-vue](https://github.com/vuejs/eslint-plugin-vue/pull/2226) to switch the repo to flat config * **2023-07-09** - PR: [Pull request to eslint-plugin-react](https://github.com/jsx-eslint/eslint-plugin-react/pull/3600) to switch to flat config * **2023-07-14** - [ESLint v8.45.0 was released](https://eslint.org/blog/2023/07/eslint-v8.45.0-released/) with feature-complete flat config and a config migration guide * **2023-08-03** - Blog: [ESLint’s new config system, Part 1: Background](https://eslint.org/blog/2022/08/new-config-system-part-1/) * **2023-08-05** - Blog: [ESLint’s new config system, Part 2: Introduction to flat config](https://eslint.org/blog/2022/08/new-config-system-part-2/) * **2023-08-08** - Blog: [ESLint’s new config system, Part 3: Developer preview](https://eslint.org/blog/2022/08/new-config-system-part-3/) * **2023-09-26** - Blog: [Preparing your custom rules for ESLint v9.0.0](https://eslint.org/blog/2023/09/preparing-custom-rules-eslint-v9/) * **2023-10-10** - Blog: [Flat config rollout plans](https://eslint.org/blog/2023/10/flat-config-rollout-plans/) * **2023-11-07** - Blog: [What’s coming in ESLint v9.0.0](https://eslint.org/blog/2023/11/whats-coming-in-eslint-9.0.0/) * **2023-12-29** - [ESLint v9.0.0-alpha.0 released](https://eslint.org/blog/2023/12/eslint-v9.0.0-alpha.0-released/) * **2024-01-12** - [ESLint v9.0.0-alpha.1 released](https://eslint.org/blog/2024/01/eslint-v9.0.0-alpha.1-released/) * **2024-01-26** - [ESLint v9.0.0-alpha.2 released](https://eslint.org/blog/2024/01/eslint-v9.0.0-alpha.2-released/) * **2024-02-09** - [ESLint v9.0.0-beta.0 released](https://eslint.org/blog/2024/02/eslint-v9.0.0-beta.0-released/) * **2024-02-23** - [ESLint v9.0.0-beta.1 released](https://eslint.org/blog/2024/02/eslint-v9.0.0-beta.1-released/) * **2024-03-08** - [ESLint v9.0.0-beta.2 released](https://eslint.org/blog/2024/03/eslint-v9.0.0-beta.2-released/) * **2024-03-22** - [ESLint v9.0.0-rc.0 released](https://eslint.org/blog/2024/03/eslint-v9.0.0-rc.0-released/) * **2024-04-05** - [ESLint v9.0.0 released](https://eslint.org/blog/2024/04/eslint-v9.0.0-released//) The development of the new configuration system spanned more than five years, from the initial RFC to the final release. The API preview shipped in v8.21.0 on August 1, 2022, followed by the CLI preview in v8.23.0 on August 26, which allowed users to opt in to flat config. From there, we continued refining the system, fixing bugs and smoothing out the design. We considered the configuration system feature complete with ESLint v8.45.0, released on July 14, 2023. That set the stage for it to become the default in ESLint v9.0.0 on April 5, 2024. Here are a few key stats from that timeline: * Nearly *five years* passed from initial flat config RFC to the final release * Flat config was available in the CLI for *20 months* before v9.0.0 * Flat config was feature complete for *eight months* before the v9.0.0 release * There were seven prereleases over *four months* with flat config as the default #### What went right Here’s what went according to plan with the v9.0.0 release. ##### Formalizing a version support policy; partnered with HeroDevs For the first time, we formalized a [version support policy](https://eslint.org/version-support/) for older ESLint releases. This stemmed from discussions with [HeroDevs](https://herodevs.com) about [never-ending support](https://www.herodevs.com/support/eslint-nes?utm_source=ESLintWebsite&utm_medium=ESLintWebsite&utm_campaign=ESLintNES&utm_id=ESLintNES). They emphasized the importance of clearly stating what support older releases would receive and when it would end. In the past, support for the previous major version was cut off immediately, but this was undocumented. With the scope of changes in v9.0.0, we recognized that approach would be too disruptive. ##### Backporting fixes to v8.x We supported the v8.x release line for six months after the v9.0.0 release, backporting bug fixes and compatibility updates related to the new configuration system. After that, HeroDevs took over maintenance of v8.x and earlier versions. This was the first time we supported two release lines simultaneously. It required overhauling our infrastructure to support publishing from multiple branches, not just `main`. We also updated the homepage to clearly show which release was stable and which was in prerelease. ##### Documentation and communication We produced extensive documentation for the v9.0.0 release, including blog posts and migration guides. In many ways, it was the most thoroughly documented ESLint release to date. We also introduced a new process: the [v9.0.0 migration guide](https://eslint.org/docs/latest/use/migrate-to-9.0.0) was updated in the same pull request as each new feature. Previously, we wrote the guide after all features had been merged, increasing the chance of omissions. This new approach helped ensure nothing was missed. ##### Expecting and responding to the chaos From past experience, we knew that migrating to a major release is often a slow and difficult process. Despite extensive testing, we expected issues. When things don’t work immediately, users typically delay upgrades until they have time to investigate. This pattern has held true for every major ESLint release. We anticipated a flood of early feedback, which ultimately led to the release of tools like the [compatibility utilities](https://eslint.org/blog/2024/05/eslint-compatibility-utilities/), the [Config Inspector](https://eslint.org/blog/2024/04/eslint-config-inspector/), and the [Config Migrator](https://eslint.org/blog/2024/05/eslint-configuration-migrator/). The team responded quickly and constructively, even when feedback was critical. Those efforts are now paying off, as new adopters of ESLint v9.x are seeing a much smoother upgrade path. #### What went wrong While we’re proud of the progress made with ESLint v9.0.0, there were areas where things didn’t go as planned. ##### Too many breaking changes The biggest mistake was bundling too many breaking changes into a single major release. A key example was introducing the new configuration system alongside the [rule API changes](https://eslint.org/blog/2023/09/preparing-custom-rules-eslint-v9/), both of which were necessary steps to enable [language plugins](https://eslint.org/docs/latest/extend/languages). This often made it difficult to pinpoint the cause of issues with existing plugins. Many assumed the new configuration system was to blame, creating a narrative that it was “broken” or “not ready.” In reality, the rule API changes were just as disruptive. We were so focused on the configuration system rollout that we underestimated the impact of the rule API changes. ##### Too much documentation and not enough tooling We thought that providing extensive documentation would ease the expected upgrade pain. We published [release notes](https://eslint.org/blog/2024/04/eslint-v9.0.0-released/), a [v9.0.0 migration guide](https://eslint.org/docs/latest/use/migrate-to-9.0.0), a [configuration migration guide](https://eslint.org/docs/latest/use/configure/migration-guide), and a [plugin migration guide](https://eslint.org/docs/latest/extend/plugin-migration-flat-config), believing we had covered all the important changes. What we didn’t anticipate was that this amount of documentation would be overwhelming for most users. Our assumption was that users would read the release notes, then the migration guide, and finally install v9.0.0. Instead, many installed it, encountered an error message about a missing configuration file, and only then returned to the documentation for guidance. Many users sought help in Discord or GitHub without reading the docs first. As one user put it: “I don’t have a spare two hours to read through all the documentation and figure out how to upgrade my config file. Just do it for me automatically.” ##### Ecosystem adoption was slow Despite the long development cycle for the new configuration system and our direct outreach to high-profile plugin and shareable config authors (see the timeline for details), the ecosystem took longer to adapt than expected. Many plugin and config authors didn’t begin adapting their packages until v9.0.0 was in beta. Some suggested delaying the v9.0.0 release to give the ecosystem more time to catch up. We decided against this for several reasons: * Users weren’t required to upgrade immediately. ESLint v8.x remained fully compatible with the ecosystem and continued receiving bug fixes, so those who didn’t want to upgrade could continue using it. * It was unclear how long such a delay would last. How could we determine when the ecosystem had “caught up”? Should we keep v9.0.0 in limbo while only providing bug fixes for v8.x indefinitely? That didn’t seem like a viable solution. * The [`@eslint/eslintrc`](https://github.com/eslint/eslintrc) package already offered substantial compatibility for eslintrc plugins and shareable configs with v9.0.0, addressing the most common issues we encountered. * We had communicated the upcoming changes for 18 months, with increasing reminders as we neared the first alpha release. Although adoption was slower than expected, we saw momentum building and wanted to maintain that pace. Delaying the release could have sent the wrong message and allowed further delays to snowball. ##### We didn’t anticipate the desire for dual-config plugin support It became clear late in the process that many plugin and shareable config authors wanted to provide a single package compatible with both the old and new configuration systems. Although this seems obvious in hindsight, we initially assumed authors would either release a new version of their plugin for ESLint v9.0.0 and stop supporting v8.x, or maintain separate release lines for v8.x and v9.x. However, many ecosystem maintainers expressed a strong desire for dual-config support. #### Lessons learned From our experience with the ESLint v9.0.0 release, we’ve identified key lessons: * **Too many breaking changes:** Looking back, bundling the configuration system change with the rule API change created too many disruptions. In the future, we will prioritize smaller, more frequent major releases instead of larger, less frequent ones. * **Tooling first, documentation second:** Users often do not have time to thoroughly read release notes or migration guides. We will focus more on tooling like codemods and conversion utilities to help users get started quickly. * **Errors need context:** Given that many users will install a major release before reading the release notes, we will improve error messages to provide more context and direct users to relevant documentation. * **Ecosystem outreach needs improvement:** We need to find more effective ways to engage the ecosystem when significant changes are on the horizon. Our previous methods, including blog posts, social media, and direct outreach via email and pull requests, were not as effective as we had hoped. #### Conclusion The release of ESLint v9.0.0 was a significant milestone, and while we are proud of many aspects of the rollout, it highlighted areas where we can improve. By focusing on smaller, more manageable changes in future major releases, prioritizing tooling over documentation, and refining our ecosystem outreach, we can make the upgrade process smoother for everyone. The lessons learned from v9.0.0 will guide us as we continue to evolve ESLint and work to meet the needs of our users. We appreciate the ongoing feedback from the community and are committed to making ESLint a more reliable and user-friendly tool moving forward., ESLint V9.0.0: A Retrospective, eslint.org, 01jw8t5mg25n0q11x1pb1ydp8t.