14 ms·

Complete Rewrite of ESLint

162 points by georgehill 4y ago

AbuAssar 4y ago
> I don't want to rewrite in TypeScript, because I believe the core of ESLint should be vanilla JS why though?
- redox99 4y ago
  The fact that they would use JSDoc type annotations and tsc instead of just typescript seems insane to me.
  - have_faith 4y ago
    Yeah, surely in some hypothetical future it's not that much work to simply go back to plain JS from TS if they're worried about some sort of lock-in. Seems like you might as well just write it in TS then if it's relatively trivial to eject if needed.
  - adamddev1 4y ago
    Ya I am also perplexed about how people keep suggesting using jsdoc instead of TypeScript. Is it just to avoid the tooling?
    - NateEag 4y ago
      I think it's to maximize potential contributor base. JS is the front-end browser language. That's its origin story and it almost certainly will always have that job, because of web browser backwards compatibility. That's why it's so universally known / used / understood. Once you target TypeScript you're suddenly looking at a much smaller set of devs who know it, and you're married to a language that's effectively owned by a single company (MS, to boot). You can get decent gains in type-checking by writing JSDoc and using tsc in your build process without adding much friction for new contributors.
      - tonto 4y ago
        I think its more that eslint at its core does not support typescript and they want to run the eslint tool theyre developing over the eslint codebase. It's hard to argue with this but it doesnt seem like the greatest outcome
      - madeofpalk 4y ago
        I would guess that more people know how to write Typescript than annotate with JSDoc.
      - ohbtvz 4y ago
        The kind of people who'd be willing to contribute to eslint are very probably not afraid of writing in typescript.
    - tytho 4y ago
      From personal experience, you don’t ever “just use TypeScript”. You have to install plugins, adapters, parsers for every other tool (linters, formatters, bundlers) to also make them work with TypeScript. Adding TypeScript into the mix increases the number of dependencies (dev or not) dramatically. If you use the jsdoc flavor of TypeScript, you only need to install the one dependency. Not saying it’s the best reason, but a reason nonetheless.
      - robby_w_g 4y ago
        Over the weekend, I converted an app from JS + Create React App to Typescript + Parcel v2. The typescript tooling was extremely simple to setup with only a few added packages... until I had to setup eslint. That's when I had to install a half dozen plugins, adapters, parsers, etc like you said. Granted, the linked eslint rewrite seems to have plans to make the typescript linting tooling simpler. However, I might end up switching to Rome in the meantime just for simpler dependency management.
        Aeolun 4y ago
        Rome is very nice right now. My linting finishes in 50ms, as it’s supposed to, instead of minutes in eslint. Of course they don’t have nearly the same amount of rules, but we’ll get there.
        robby_w_g 4y ago
        My project currently pulls in the airbnb rules, which in my opinion has too many rules. It might be nice to start from a clean slate, I'll give Rome a shot next weekend
  - satvikpendem 4y ago
    Just the other day I read this thread on Reddit about the link above and this thread stood out to me. This person uses TypeScript files to define types, then uses JSDoc to import the types into JS. They said they didn't want a build tool but I agree, it seemed insane to me. https://old.reddit.com/r/javascript/comments/z4lwlo/complete_rewrite_of_eslint_github_discussion_by/ixtmt3r/?context=99 https://old.reddit.com/r/javascript/comments/z4lwlo/complete...
- echeese 4y ago
  Probably so they can run it through ESLint
TheFragenTaken 4y ago
I'm curious if anyone else has noticed this? It seems Rust is tending towards "silver bullet"-status, as if; if it's written in Rust, it must be fast. I'm not here to rain on Rust'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.
- maeln 4y ago
  I agree that it is completely possible to write slow code in Rust, but the idea is still that, in general with a relatively skilled developer, a compiled langage will usually result in a faster program than with a interpreted or jit-ed langage. So, assuming you are competent in said langage, you might as well write it in your compiled langage of choice, assuming performance is one of your major priority.
  - deleted 4y ago
    [deleted]
  - JonChesterfield 4y ago
    A jit can tune itself to properties of input data which were unknown at compile time. That's a serious advantage for long running programs that don't know much about their input, which might be the important ones. That might still be the realm of the sufficiently smart compiler though, aka vapourware, so in practice today you're probably right.
- melling 4y ago
  I’m not a Rust developer and I’ve been waiting for it to bake a few more years before playing with it. However, I do appreciate the desire for developers to use languages that allow for more performance and fewer bugs, catching more bugs at compile time. Even small improvements are important. Ideally, poorly written, but correct, code in such a language could be refactored more easily in such a language.
- bovermyer 4y ago
sph 4y ago
> Rust-based replacements 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. While Rust was born to be a better C++, but is getting a lot of traction with Javascript/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). I guess the hype-driven junior developers saw how better Typescript is at managing Javascript's shortcomings, and now see static typed languages, especially one with some hype of its own behind, as the Messiah. Let me add the disclaimer that I'm a fan of Rust before I get attacked for this controversial observation.
- acdha 4y ago
  I’m seeing a lot of Rust in the Python world, too, which I think makes sense as people want to avoid the hostility of C/C++ and expect developer ergonomics closer to the level they’re familiar with rather than the C/C++/Go-level toil.
  - rob74 4y ago
    Not sure what you are thinking of when you put C, C++ and Go into the same category of "bad developer ergonomics" here? I found Go's developer ergonomics to be pretty welcoming, compared to C/C++ and also compared to Node for that matter...
    - acdha 4y ago
      It’s a spectrum where I’d definitely rank Go higher than the others but package management and error handling were historically a disappointment.
- cle 4y ago
  It helps that Rust is probably the best language to use if you are targeting Wasm, which is mentioned in the discussion. Go can be compiled to Wasm too, but the fat runtime makes it a non-starter for many use cases. (I prefer Go over Rust for general purpose programming, and I wish that Wasm had an answer here so we can use less complex, cognitively-lighter languages.)
losvedir 4y ago
Ambitious! I've always been curious about the trade-off between "second-system syndrome" and "learning from experience". Do people have examples of rewrites that went well and those that didn't? I can think of several that didn'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't think of many that did go well. 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's ripgrep is an example of someone else doing a rewrite that worked out pretty well. Others?
- mwint 4y ago
  The classic Joel article: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
  - capableweb 4y ago
    It's a bit ironic to use Netscape as an example of a "rewrite gone wrong" as (if I remember correctly) the initial version of Netscape was a complete rewrite of Mosaic, with Mosaic developers being involved in the rewrite as well. And I think Netscape in general was quite popular, most if not all software people were using Netscape at one point if they were active during that time.
    - mixmastamyk 4y ago
      Every new program is a “rewrite” if you look back far enough. In that case they had funding to start a new company and the problem space was an order of magnitude smaller. He’s right, that decision marked the end of Netscape as a factor.
- Brybry 4y ago
  Twitch rewrote their backend from Rails to Go. They also rewrote their frontend in React (previously Ember.js)[1] I know I've also seen a Twitch developer stream themselves benchmarking Rust + io_uring vs Go but I don't know if anything ever came of that. Discord rewrote at least one Go service in Rust. [2] Cloudflare made Pingora (Rust) to use instead of NGINX (C) though idk if that meets the rewrite criteria. [3] [1] https://blog.twitch.tv/en/2022/03/30/breaking-the-monolith-at-twitch/ https://blog.twitch.tv/en/2022/03/30/breaking-the-monolith-a... [2] https://discord.com/blog/why-discord-is-switching-from-go-to-rust https://discord.com/blog/why-discord-is-switching-from-go-to... [3] https://blog.cloudflare.com/how-we-built-pingora-the-proxy-that-connects-cloudflare-to-the-internet/ https://blog.cloudflare.com/how-we-built-pingora-the-proxy-t...
rattray 4y ago
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.
- deleted 4y ago
  [deleted]
- ohbtvz 4y ago
  You could write an identical comment under most JS-related threads.
rattray 4y ago
I have to say, I think they'd be crazy not to write the new version in TypeScript. 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. It'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.
- h1fra 4y ago
  it's even weirder to say that and then say that you will add jsdoc, use tsc and publish types = having the exact the same processes without having a .ts at the end ahah
  - hajile 4y ago
    JSdoc comments are 100% JS while TS types are not. This means you will be able to run ESLint without a TS compiler while still having types for people who want them. It's also more future-proof for if/when JS adopts a type system that may or may not be compatible with TS. This sounds like everyone wins except the people who are overly-dogmatic about TS.
    - EduardoBautista 4y ago
      If ESLint were rewritten in TS, you would still be able to run it without the TS compiler, since it would already be compiled into regular JS when published to NPM.
      - hajile 4y ago
        Why should you be forced to deliver via NPM? What about Deno or people using it in web-only contexts? If they use ES-compliant modules, a build step isn't even required. Once again, it's not that they don't have types, but the TS fanboys are now complaining that it's "not the right types".
NateEag 4y ago
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.
    - 4y ago
acdibble 4y ago
> Make ESLint type-aware. This seems to be something we keep banging our heads against -- we just don't have any way of knowing what type of value a variable contains. If we knew that, we'd be able to catch a lot more errors. Maybe we could find a way to consume TypeScript data for this? 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. [1] https://typescript-eslint.io/docs/linting/typed-linting https://typescript-eslint.io/docs/linting/typed-linting
conaclos 4y ago
I'm wondering if the first stable release of Rome [1] JS/TS linter has influenced this announcement. [1] https://rome.tools https://rome.tools
- EduardoBautista 4y ago
  If it did, the ESLint rebuild discussion is ignoring one huge advantage Rome has that the ESLint rebuild will not have: Rust performance.
  - davidjfelix 4y ago
    They do state in the link that some portions may be written in rust for performance.
  - ezekg 4y ago
    Actually, Rust-based implementations are mentioned under Goals, item 6. It looks like ESLint wants to compete with all Rome can do.
canyonero 4y ago
I'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! Any discussion these days around eslint reminds me of a new situation that still has me very confused where I've encountered a team of engineers that refuse to allow any formatting on their code. Are there any folks that run large JS/TS codebases with no automated linting/formatting by choice and maybe feel similarly or worked with other teams that do? I've come to expect eslint (and prettier) to be pretty much a given for a large JS/TS codebase.
- conaclos 4y ago
  For anyone wondering, Rome [1] is a new JS/TS/JSON formatter and linter written in Rust. [1] https://rome.tools https://rome.tools
  - yewenjie 4y ago
    I wish rome lint was a drop-in replacement for ESLint.
    - conaclos 4y ago
      It will be pretty close to that. They are talking about a tool for migrating ESLint configs in the future.
  - Aeolun 4y ago
    It’s not a JSON formatter yet :P
wwwigham 4y ago
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).
- swyx 4y ago
  also note that both Deno and Sveltekit moved from TypeScript to JSDoc (https://twitter.com/swyx/status/1350427690814251010 https://twitter.com/swyx/status/1350427690814251010)
  - e12e 4y ago
    For Deno at least, there were some pretty specific reasons for the change: https://docs.google.com/document/u/0/d/1_WvwHl7BXUPmoiSeD8G83JmS8ypsTPqed4Btkqkn_-4/mobilebasic#heading=h.cx5nx247bag https://docs.google.com/document/u/0/d/1_WvwHl7BXUPmoiSeD8G8...
- Aeolun 4y ago
  I’m kind of inclined to say that eslint won because they have typescript evaluation as well. If it didn’t work on Typescript you’d see less and less people using it.
an1sotropy 4y ago
If they pull this off, does this mean we can use ESLint in a directory where I haven't (and don't need to) run "npm init"?
truth_seeker 4y ago
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 ? ;)
- klysm 4y ago
  Not sure that’s particularly relevant. I think people take issue with it because it has impacts on the stability and reliability of the result
branko_d 4y ago
Here is the Joel Spolsky‘s obligatory argument against code rewrites: Things You Should Never Do, Part I https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... While I don’t necessarily agree that we should never ever rewrite, he is making some good points that we can ignore at our own peril…
- strawhatguy 4y ago
  yeah, was thinking this. Of course, in this space I don't think eslint has many competitors, unlike Netscape vs IE did then, so they've got time.. for now. I'm sure 'old' eslint will be mostly ignored in the meantime, as the excitement will be with the new shiny.

162 points by georgehill 4y ago

AbuAssar 4y ago

> I don't want to rewrite in TypeScript, because I believe the core of ESLint should be vanilla JS why though?

redox99 4y ago
The fact that they would use JSDoc type annotations and tsc instead of just typescript seems insane to me.
- have_faith 4y ago
  Yeah, surely in some hypothetical future it's not that much work to simply go back to plain JS from TS if they're worried about some sort of lock-in. Seems like you might as well just write it in TS then if it's relatively trivial to eject if needed.
- adamddev1 4y ago
  Ya I am also perplexed about how people keep suggesting using jsdoc instead of TypeScript. Is it just to avoid the tooling?
  - NateEag 4y ago
    I think it's to maximize potential contributor base. JS is the front-end browser language. That's its origin story and it almost certainly will always have that job, because of web browser backwards compatibility. That's why it's so universally known / used / understood. Once you target TypeScript you're suddenly looking at a much smaller set of devs who know it, and you're married to a language that's effectively owned by a single company (MS, to boot). You can get decent gains in type-checking by writing JSDoc and using tsc in your build process without adding much friction for new contributors.
    - tonto 4y ago
      I think its more that eslint at its core does not support typescript and they want to run the eslint tool theyre developing over the eslint codebase. It's hard to argue with this but it doesnt seem like the greatest outcome
    - madeofpalk 4y ago
      I would guess that more people know how to write Typescript than annotate with JSDoc.
    - ohbtvz 4y ago
      The kind of people who'd be willing to contribute to eslint are very probably not afraid of writing in typescript.
  - tytho 4y ago
    From personal experience, you don’t ever “just use TypeScript”. You have to install plugins, adapters, parsers for every other tool (linters, formatters, bundlers) to also make them work with TypeScript. Adding TypeScript into the mix increases the number of dependencies (dev or not) dramatically. If you use the jsdoc flavor of TypeScript, you only need to install the one dependency. Not saying it’s the best reason, but a reason nonetheless.
    - robby_w_g 4y ago
      Over the weekend, I converted an app from JS + Create React App to Typescript + Parcel v2. The typescript tooling was extremely simple to setup with only a few added packages... until I had to setup eslint. That's when I had to install a half dozen plugins, adapters, parsers, etc like you said. Granted, the linked eslint rewrite seems to have plans to make the typescript linting tooling simpler. However, I might end up switching to Rome in the meantime just for simpler dependency management.
      - Aeolun 4y ago
        Rome is very nice right now. My linting finishes in 50ms, as it’s supposed to, instead of minutes in eslint. Of course they don’t have nearly the same amount of rules, but we’ll get there.
        robby_w_g 4y ago
        My project currently pulls in the airbnb rules, which in my opinion has too many rules. It might be nice to start from a clean slate, I'll give Rome a shot next weekend
- satvikpendem 4y ago
  Just the other day I read this thread on Reddit about the link above and this thread stood out to me. This person uses TypeScript files to define types, then uses JSDoc to import the types into JS. They said they didn't want a build tool but I agree, it seemed insane to me. https://old.reddit.com/r/javascript/comments/z4lwlo/complete_rewrite_of_eslint_github_discussion_by/ixtmt3r/?context=99 https://old.reddit.com/r/javascript/comments/z4lwlo/complete...
echeese 4y ago
Probably so they can run it through ESLint

TheFragenTaken 4y ago

I'm curious if anyone else has noticed this? It seems Rust is tending towards "silver bullet"-status, as if; if it's written in Rust, it must be fast. I'm not here to rain on Rust'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.

maeln 4y ago
I agree that it is completely possible to write slow code in Rust, but the idea is still that, in general with a relatively skilled developer, a compiled langage will usually result in a faster program than with a interpreted or jit-ed langage. So, assuming you are competent in said langage, you might as well write it in your compiled langage of choice, assuming performance is one of your major priority.
- deleted 4y ago
  [deleted]
- JonChesterfield 4y ago
  A jit can tune itself to properties of input data which were unknown at compile time. That's a serious advantage for long running programs that don't know much about their input, which might be the important ones. That might still be the realm of the sufficiently smart compiler though, aka vapourware, so in practice today you're probably right.
melling 4y ago
I’m not a Rust developer and I’ve been waiting for it to bake a few more years before playing with it. However, I do appreciate the desire for developers to use languages that allow for more performance and fewer bugs, catching more bugs at compile time. Even small improvements are important. Ideally, poorly written, but correct, code in such a language could be refactored more easily in such a language.
bovermyer 4y ago

sph 4y ago

> Rust-based replacements 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. While Rust was born to be a better C++, but is getting a lot of traction with Javascript/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). I guess the hype-driven junior developers saw how better Typescript is at managing Javascript's shortcomings, and now see static typed languages, especially one with some hype of its own behind, as the Messiah. Let me add the disclaimer that I'm a fan of Rust before I get attacked for this controversial observation.

acdha 4y ago
I’m seeing a lot of Rust in the Python world, too, which I think makes sense as people want to avoid the hostility of C/C++ and expect developer ergonomics closer to the level they’re familiar with rather than the C/C++/Go-level toil.
- rob74 4y ago
  Not sure what you are thinking of when you put C, C++ and Go into the same category of "bad developer ergonomics" here? I found Go's developer ergonomics to be pretty welcoming, compared to C/C++ and also compared to Node for that matter...
  - acdha 4y ago
    It’s a spectrum where I’d definitely rank Go higher than the others but package management and error handling were historically a disappointment.
cle 4y ago
It helps that Rust is probably the best language to use if you are targeting Wasm, which is mentioned in the discussion. Go can be compiled to Wasm too, but the fat runtime makes it a non-starter for many use cases. (I prefer Go over Rust for general purpose programming, and I wish that Wasm had an answer here so we can use less complex, cognitively-lighter languages.)

losvedir 4y ago

Ambitious! I've always been curious about the trade-off between "second-system syndrome" and "learning from experience". Do people have examples of rewrites that went well and those that didn't? I can think of several that didn'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't think of many that did go well. 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's ripgrep is an example of someone else doing a rewrite that worked out pretty well. Others?

mwint 4y ago
The classic Joel article: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- capableweb 4y ago
  It's a bit ironic to use Netscape as an example of a "rewrite gone wrong" as (if I remember correctly) the initial version of Netscape was a complete rewrite of Mosaic, with Mosaic developers being involved in the rewrite as well. And I think Netscape in general was quite popular, most if not all software people were using Netscape at one point if they were active during that time.
  - mixmastamyk 4y ago
    Every new program is a “rewrite” if you look back far enough. In that case they had funding to start a new company and the problem space was an order of magnitude smaller. He’s right, that decision marked the end of Netscape as a factor.
Brybry 4y ago
Twitch rewrote their backend from Rails to Go. They also rewrote their frontend in React (previously Ember.js)[1] I know I've also seen a Twitch developer stream themselves benchmarking Rust + io_uring vs Go but I don't know if anything ever came of that. Discord rewrote at least one Go service in Rust. [2] Cloudflare made Pingora (Rust) to use instead of NGINX (C) though idk if that meets the rewrite criteria. [3] [1] https://blog.twitch.tv/en/2022/03/30/breaking-the-monolith-at-twitch/ https://blog.twitch.tv/en/2022/03/30/breaking-the-monolith-a... [2] https://discord.com/blog/why-discord-is-switching-from-go-to-rust https://discord.com/blog/why-discord-is-switching-from-go-to... [3] https://blog.cloudflare.com/how-we-built-pingora-the-proxy-that-connects-cloudflare-to-the-internet/ https://blog.cloudflare.com/how-we-built-pingora-the-proxy-t...

rattray 4y ago

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.

deleted 4y ago
[deleted]
ohbtvz 4y ago
You could write an identical comment under most JS-related threads.

rattray 4y ago

I have to say, I think they'd be crazy not to write the new version in TypeScript. 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. It'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.

h1fra 4y ago
it's even weirder to say that and then say that you will add jsdoc, use tsc and publish types = having the exact the same processes without having a .ts at the end ahah
- hajile 4y ago
  JSdoc comments are 100% JS while TS types are not. This means you will be able to run ESLint without a TS compiler while still having types for people who want them. It's also more future-proof for if/when JS adopts a type system that may or may not be compatible with TS. This sounds like everyone wins except the people who are overly-dogmatic about TS.
  - EduardoBautista 4y ago
    If ESLint were rewritten in TS, you would still be able to run it without the TS compiler, since it would already be compiled into regular JS when published to NPM.
    - hajile 4y ago
      Why should you be forced to deliver via NPM? What about Deno or people using it in web-only contexts? If they use ES-compliant modules, a build step isn't even required. Once again, it's not that they don't have types, but the TS fanboys are now complaining that it's "not the right types".

NateEag 4y ago

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.
  - 4y ago

acdibble 4y ago

> Make ESLint type-aware. This seems to be something we keep banging our heads against -- we just don't have any way of knowing what type of value a variable contains. If we knew that, we'd be able to catch a lot more errors. Maybe we could find a way to consume TypeScript data for this? 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. [1] https://typescript-eslint.io/docs/linting/typed-linting https://typescript-eslint.io/docs/linting/typed-linting

conaclos 4y ago

I'm wondering if the first stable release of Rome [1] JS/TS linter has influenced this announcement. [1] https://rome.tools https://rome.tools

EduardoBautista 4y ago
If it did, the ESLint rebuild discussion is ignoring one huge advantage Rome has that the ESLint rebuild will not have: Rust performance.
- davidjfelix 4y ago
  They do state in the link that some portions may be written in rust for performance.
- ezekg 4y ago
  Actually, Rust-based implementations are mentioned under Goals, item 6. It looks like ESLint wants to compete with all Rome can do.

canyonero 4y ago

I'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! Any discussion these days around eslint reminds me of a new situation that still has me very confused where I've encountered a team of engineers that refuse to allow any formatting on their code. Are there any folks that run large JS/TS codebases with no automated linting/formatting by choice and maybe feel similarly or worked with other teams that do? I've come to expect eslint (and prettier) to be pretty much a given for a large JS/TS codebase.

conaclos 4y ago
For anyone wondering, Rome [1] is a new JS/TS/JSON formatter and linter written in Rust. [1] https://rome.tools https://rome.tools
- yewenjie 4y ago
  I wish rome lint was a drop-in replacement for ESLint.
  - conaclos 4y ago
    It will be pretty close to that. They are talking about a tool for migrating ESLint configs in the future.
- Aeolun 4y ago
  It’s not a JSON formatter yet :P

wwwigham 4y ago

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).

swyx 4y ago
also note that both Deno and Sveltekit moved from TypeScript to JSDoc (https://twitter.com/swyx/status/1350427690814251010 https://twitter.com/swyx/status/1350427690814251010)
- e12e 4y ago
  For Deno at least, there were some pretty specific reasons for the change: https://docs.google.com/document/u/0/d/1_WvwHl7BXUPmoiSeD8G83JmS8ypsTPqed4Btkqkn_-4/mobilebasic#heading=h.cx5nx247bag https://docs.google.com/document/u/0/d/1_WvwHl7BXUPmoiSeD8G8...
Aeolun 4y ago
I’m kind of inclined to say that eslint won because they have typescript evaluation as well. If it didn’t work on Typescript you’d see less and less people using it.

an1sotropy 4y ago

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

truth_seeker 4y ago

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 ? ;)

klysm 4y ago
Not sure that’s particularly relevant. I think people take issue with it because it has impacts on the stability and reliability of the result

branko_d 4y ago

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

strawhatguy 4y ago
yeah, was thinking this. Of course, in this space I don't think eslint has many competitors, unlike Netscape vs IE did then, so they've got time.. for now. I'm sure 'old' eslint will be mostly ignored in the meantime, as the excitement will be with the new shiny.