Complete Rewrite of ESLint

Contrary to what seems to be popular opinion here on HN, I think it's fine they'd entertain keeping their code as JS with JSDoc, rather than TS. It's still typesafe, which is what's important from a maintenance and documentation perspective. A linter than goes all in on TS is what tslint was (and it worked on JS), and ultimately it lost to eslint in the linter popularity wars (as has jslint, and jshint, imo). If JS source is the sauce that keeps contributions coming and the downloads flowing, then so be it. There's also some value in dogfooding their own JS lints, rather than TS ones. Sure, there's overlap, but undoubtedly some differences, too (especially any rule that lints jsdoc).

Ambitious!<p>I&#x27;ve always been curious about the trade-off between &quot;second-system syndrome&quot; and &quot;learning from experience&quot;. Do people have examples of rewrites that went well and those that didn&#x27;t?<p>I can think of several that didn&#x27;t go well (and in fact ultimately decided as tech lead at my last place not to do one for a big chunk of our code that I was on the fence about, just because of that), but can&#x27;t think of many that did go well.<p>Maybe Go is kind of an example where the authors used all their experience to build something new, rather than just a straight up rewrite. BurntSushi&#x27;s ripgrep is an example of someone else doing a rewrite that worked out pretty well. Others?

I twitched when I read this issue, because rewrites so rarely end well.<p>I&#x27;d recommend a different strategy, personally:<p>Write a POC linter that demonstrates the features you think ESLint is missing, with no regard for interface consistency or backwards compatibility.<p>Once that&#x27;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.<p>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 &quot;nuke everything in the new branch&quot;.<p>You&#x27;d keep continuity of history for any files that aren&#x27;t completely deleted, and you might find that you don&#x27;t need to gut things as thoroughly as you expect.

&gt; I don&#x27;t want to rewrite in TypeScript, because I believe the core of ESLint should be vanilla JS<p>why though?

I have to say, I think they&#x27;d be crazy not to write the new version in TypeScript.<p>Choosing to use JS without TS at this point has become a dogmatic statement of purism that, while beautiful in a sense, is so unpragmatic as to appear a little foolish.<p>It&#x27;s like insisting on using the pre-electronics version of a powerful, dangerous machine even though the new version gives you just as much control, greater precision, and much better safety, because of a romantic notion of purity in the way things should be done. Admirable and not at the same time.

I&#x27;m curious if anyone else has noticed this? It seems Rust is tending towards &quot;silver bullet&quot;-status, as if; if it&#x27;s written in Rust, it must be fast.<p>I&#x27;m not here to rain on Rust&#x27;s parade, but you can absolutely write unmaintainable, slow Rust code. I would even argue, beginners write fewer features that perform worse, in the same amount of time, than their main-language (in this example: Javascript) counterparts. Especially if they have years of experience.

Major projects like this are somewhat rare in the open, and often interesting. It sounds high-risk, but if done well could make a big positive difference in the world of js-related software development.

Here is the Joel Spolsky‘s obligatory argument against code rewrites:<p>Things You Should Never Do, Part I<p><a href="https:&#x2F;&#x2F;www.joelonsoftware.com&#x2F;2000&#x2F;04&#x2F;06&#x2F;things-you-should-never-do-part-i&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.joelonsoftware.com&#x2F;2000&#x2F;04&#x2F;06&#x2F;things-you-should-...</a><p>While I don’t necessarily agree that we should <i>never ever</i> rewrite, he is making some good points that we can ignore at our own peril…

&gt; Make ESLint type-aware. This seems to be something we keep banging our heads against -- we just don&#x27;t have any way of knowing what type of value a variable contains. If we knew that, we&#x27;d be able to catch a lot more errors. Maybe we could find a way to consume TypeScript data for this?<p>An ESLint plugin manages to do this well[1]. Would be nice to have this functionality built in natively although you do take a performance hit because you have to run the compiler.<p>[1] <a href="https:&#x2F;&#x2F;typescript-eslint.io&#x2F;docs&#x2F;linting&#x2F;typed-linting" rel="nofollow">https:&#x2F;&#x2F;typescript-eslint.io&#x2F;docs&#x2F;linting&#x2F;typed-linting</a>

I&#x27;ve been sensing this coming for some time given what Rome has been working on. Will be interesting to see how the rewrite pans out!<p>Any discussion these days around eslint reminds me of a new situation that still has me very confused where I&#x27;ve encountered a team of engineers that refuse to allow any formatting on their code. Are there any folks that run large JS&#x2F;TS codebases with no automated linting&#x2F;formatting by choice and maybe feel similarly or worked with other teams that do? I&#x27;ve come to expect eslint (and prettier) to be pretty much a given for a large JS&#x2F;TS codebase.

Seriously ... how many of us who are debating the decision to write it in JS instead of TS are ever going to submit the PR to project or will contribute in any other meaningful way ? ;)

I&#x27;m wondering if the first stable release of Rome [1] JS&#x2F;TS linter has influenced this announcement.<p>[1] <a href="https:&#x2F;&#x2F;rome.tools" rel="nofollow">https:&#x2F;&#x2F;rome.tools</a>

If they pull this off, does this mean we can use ESLint in a directory where I haven&#x27;t (and don&#x27;t need to) run &quot;npm init&quot;?

&gt; Rust-based replacements<p>I find it funny how Go was born to be a simpler C, but managed to get a lot of mindshare with Python developers that were writing system-level scripts and backend systems.<p>While Rust was born to be a better C++, but is getting a lot of traction with Javascript&#x2F;Typescript developers, and you can start to see some similarities in the packaging and tooling philosophies of the two. (Ton of small packages, some that should probably part of the stdlib but anyone needs to use to stay sane: futures, thiserror, anyhow, for example. Also there starts to be a tendency to rewrite and release incompatible APIs that this time will solve all the problem of the previous iteration).<p>I guess the hype-driven junior developers saw how better Typescript is at managing Javascript&#x27;s shortcomings, and now see static typed languages, especially one with some hype of its own behind, as the Messiah.<p>Let me add the disclaimer that I&#x27;m a fan of Rust before I get attacked for this controversial observation.