There can be advantages to undertaking a complete library rewrite[1]: - If you've worked with the library (as a maintainer/developer, not as a user) for a long

There can be advantages to undertaking a complete library rewrite[1]: - If you've worked with the library (as a maintainer/developer, not as a user) for a long time you know where the fundamental pain points are and, after a while, the desire to get rid of those pain points can become overwhelming. - Languages evolve; what might have seemed like a good architectural decision 3 or 4 years ago may well have turned out to be a quagmire of confusion now, which new features in the language (JS examples: promises; fetch; various Array functions) can help simplify. - Rewriting from scratch can also encourage a better, more maintainable approach to code documentation (and generating online documentation from it). - Being able to dump outdated/questionable tests in favour of modern testing best practice is always welcome. - A rewrite from scratch can offer a chance to reconsider the developer experience for people who consume the library in their projects/products - though there's a danger that moving too far away from existing practices can damage trust in the library. ... Of course, rewriting from scratch is always a lot easier if your library is (relatively) obscure. I imagine the ESLint rewrite is going to be performed in the full glare of the spotlight - see already the lively conversations around the decision to not rewrite in TypeScript! [1] - Speaking from the experience of rewriting my (very obscure) JS canvas library from scratch 3 times over the past 10 years