6 ms·

I twitched when I read this issue, because rewrites so rarely end well. I'd recommend a different strategy, personally: Write a POC linter that demonstrates t

I twitched when I read this issue, because rewrites so rarely end well. I'd recommend a different strategy, personally: Write a POC linter that demonstrates the features you think ESLint is missing, with no regard for interface consistency or backwards compatibility. Once that's done, integrate it in a few real-world projects that currently use ESLint. See what the devs scream about, as well as what they like about it. With all that data in hand, now you come up with a plan for making the desired changes to existing ESLint, being willing to consider the option of "nuke everything in the new branch". You'd keep continuity of history for any files that aren't completely deleted, and you might find that you don't need to gut things as thoroughly as you expect.

halfmatthalfcat 4y ago
Didn't the moment/Luxon dev essentially do just that?
nine_k 4y ago
I could not find in the post anything saying that they are going to abandon the current ESLint and let it rot while they write a new version from scratch. > I don't believe continually to make incremental changes will get us to where ESLint needs to go if it wants to be around in another ten years. The scale of years for rewrite and migration seems right. Rewriting from scratch may make plenty of sense. A completely new architecture should not be held back by any remnants of the old implementation. The old test suite is indispensable though, and the old sets of rules are an important source to consult (even if not to directly incorporate).
- WesolyKubeczek 4y ago
  > I could not find in the post anything saying that they are going to abandon the current ESLint and let it rot while they write a new version from scratch. One thing that stands out is that they haven’t grown twice the manpower with institutional knowledge overnight. You have to put a lot of effort into your rewrite, and you have to fix bugs in the existing thing.
  - nine_k 4y ago
    They can avoid building most new features in the old codebase (because they belong to the new codebase), and limit the work on the old codebase to bug-fixing. This looks realistic.
- NateEag 4y ago
  I wasn't worried about the team letting current ESLint rot- just about the possibility of the team sinking a bunch of time into architecture, planning, add starting from scratch that never really gets anywhere. I do see your point, though.
phphphphp 4y ago
Rewrites rarely end well but that’s not a reason to never do a rewrite. The problem with rewrites is that they’re often a very expensive solution to the wrong problem. If your system is bad, it’s probably not the code at fault, it’s probably something to do with the specification or communication. However… when code is the problem, rewrites make a lot of sense. Eslint is a very well understood program, there’s absolute clarity about what it does and what it should do across contributors, and they’re constantly battling bad code. A rewrite, in this situation, where other problems have been ruled out, is probably a good option.
- NateEag 4y ago
  Thanks for sharing your thoughts. They make sense.
rikroots 4y ago
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

halfmatthalfcat 4y ago

Didn't the moment/Luxon dev essentially do just that?

nine_k 4y ago

I could not find in the post anything saying that they are going to abandon the current ESLint and let it rot while they write a new version from scratch. > I don't believe continually to make incremental changes will get us to where ESLint needs to go if it wants to be around in another ten years. The scale of years for rewrite and migration seems right. Rewriting from scratch may make plenty of sense. A completely new architecture should not be held back by any remnants of the old implementation. The old test suite is indispensable though, and the old sets of rules are an important source to consult (even if not to directly incorporate).

WesolyKubeczek 4y ago
> I could not find in the post anything saying that they are going to abandon the current ESLint and let it rot while they write a new version from scratch. One thing that stands out is that they haven’t grown twice the manpower with institutional knowledge overnight. You have to put a lot of effort into your rewrite, and you have to fix bugs in the existing thing.
- nine_k 4y ago
  They can avoid building most new features in the old codebase (because they belong to the new codebase), and limit the work on the old codebase to bug-fixing. This looks realistic.
NateEag 4y ago
I wasn't worried about the team letting current ESLint rot- just about the possibility of the team sinking a bunch of time into architecture, planning, add starting from scratch that never really gets anywhere. I do see your point, though.

phphphphp 4y ago

Rewrites rarely end well but that’s not a reason to never do a rewrite. The problem with rewrites is that they’re often a very expensive solution to the wrong problem. If your system is bad, it’s probably not the code at fault, it’s probably something to do with the specification or communication. However… when code is the problem, rewrites make a lot of sense. Eslint is a very well understood program, there’s absolute clarity about what it does and what it should do across contributors, and they’re constantly battling bad code. A rewrite, in this situation, where other problems have been ruled out, is probably a good option.

NateEag 4y ago
Thanks for sharing your thoughts. They make sense.

rikroots 4y ago

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