Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ESLint v9.0

eslint.org

Post reply on HN
Print view View original

41–49 of 49 posts

Re: ESLint v9.0

#41

Post by andenacitelli »

sunaookami wrote: post #34
theogravity wrote: post #19

I've started using https://biomejs.dev/ which is written in Rust. It's super fast compared to ESLint and doesn't require a ton of plugins to work (you just install the one @biomejs/biome package and that's it). The configuration is dead simple as well and it has VS Code and intelliJ support too. It also does formatting / prettifying in the same package as well. One downside though is it does not have support for Stan…

Biome is superb but the IntelliJ plugin is very buggy unfortunately. Still needs some time in the oven.

This has also been my experience. Linting works decently but formatting has been buggy, so I actually have time toy projects where I lint with Biome but format with Prettier.

Re: ESLint v9.0

#42

Post by thiht »

HumanOstrich wrote: post #25
AbuAssar wrote: post #8

any ES linter written in rust?

Why does it have to be written in rust?

Tools written in Rust (or Go for that matter) generally offer an extremely good user experience: good documentation, well organized CLIs with autocompletion, great performance, easy to install…

If I can, I always try to install the Rust or Go version of a tool instead of the Python or Node version.

Re: ESLint v9.0

#43

Post by Hasnep »

notnullorvoid wrote: post #28
theogravity wrote: post #19

I've started using https://biomejs.dev/ which is written in Rust. It's super fast compared to ESLint and doesn't require a ton of plugins to work (you just install the one @biomejs/biome package and that's it). The configuration is dead simple as well and it has VS Code and intelliJ support too. It also does formatting / prettifying in the same package as well. One downside though is it does not have support for Stan…

Projects like Biome and oxc seem to focus so much on reimplementing rules from eslint and broader eslint ecosystem vs. creating a plugin system for custom rules. It makes those linters virtually impossible for many projects to adopt. Seems like it's part of some larger anti composable tools trend that I really don't understand.

My experience in the Python world is that the vast majority of projects only need one or two plugins for their linter, if any. Ruff has implemented so many flake8 plugins that I'm sure it has covered 99% of projects' linting setups.

Re: ESLint v9.0

#44

Post by notnullorvoid »

Hasnep wrote: post #43
notnullorvoid wrote: post #28

Earlier quoted context omitted.

Projects like Biome and oxc seem to focus so much on reimplementing rules from eslint and broader eslint ecosystem vs. creating a plugin system for custom rules. It makes those linters virtually impossible for many projects to adopt. Seems like it's part of some larger anti composable tools trend that I really don't understand.

My experience in the Python world is that the vast majority of projects only need one or two plugins for their linter, if any. Ruff has implemented so many flake8 plugins that I'm sure it has covered 99% of projects' linting setups.

In the JS ecosystem I've seen a fair share of custom rules developed internal to engineering orgs. Someone submits a PR a couple times with the same mistakes and it's easier to write a custom rule than it is to keep reminding them and possibly others to come.

Re: ESLint v9.0

#45

Post by theogravity »

notnullorvoid wrote: post #44
Hasnep wrote: post #43

Earlier quoted context omitted.

My experience in the Python world is that the vast majority of projects only need one or two plugins for their linter, if any. Ruff has implemented so many flake8 plugins that I'm sure it has covered 99% of projects' linting setups.

In the JS ecosystem I've seen a fair share of custom rules developed internal to engineering orgs. Someone submits a PR a couple times with the same mistakes and it's easier to write a custom rule than it is to keep reminding them and possibly others to come.

This. At my workplace, we have so many custom rules because of the same mistakes.

Re: ESLint v9.0

#47

Post by steve_adams_86 »

Etheryte wrote: post #15
diob wrote: post #13

Earlier quoted context omitted.

It's in the release notes, and those also include a migration guide. I'm not sure what more you would want. It's a major version upgrade.

My qualm isn't really that it's hard to fix it once you know it's broken, or to find it in the release notes, but rather that this change doesn't need to be breaking to begin with. I can understand changing the docs and changing the default value, I can also understand dropping the plaintext config file, but why also break every project that currently relies on `.eslintrc.js`? From the tooling side, it's one extra li…

It’s a hard thing to balance. One thing first, I’m not sure the config is (or always will be) the same across versions, so it could be that eslintrc configs can’t be parsed in the first place, even if they’re js.

I can also understand wanting to move entirely to one standard. Leaving remains of the old one, with over a decade of documentation about it all over the internet, could make remaining functioning artifacts harder to debug when searched for. For example, someone is using eslint v11 and they search something like “eslintrc.js not registering”, and heaps of the results they get pertain to irrelevant versions of the software. Sure there are ways around this for the searcher (and something like copilot will surely catch these things quickly), but that doesn’t mean eslint’s GitHub issues wouldn’t risk being inundated with this type of problem for years.

I agree with you too, though. I imagine they felt they’d given it enough time and warning, and they’d prefer to keep their internals cleaner and more consistent, and their documentation simpler as well. Weird gotchas like “oh also this really old type of file we don’t technically support can still be loaded” are a bad noise when people want signals.

Re: ESLint v9.0

#48

Post by erhaetherth »

winrid wrote: post #37
8n4vidtmkvmk wrote: post #32

Earlier quoted context omitted.

Probably not. 9 is a big number. They're probably breaking too often. Should only break every few years.

Eslint released in 2013, so sounds about right. Even Java has had more major releases than that.

DataTables released in about 2008 (https://cdn.datatables.net/1.0.0/js/jquery.dataTables.js) and just released 2.0 on Feb 15 this year (https://cdn.datatables.net/2.0.0/). No BC-breaks that I'm aware of in 16 years.

Not saying every project can do it, but some of these ESLint changes seem rather unnecessary.

React always adds warnings in 1 major release and then removes in the following major release, meaning if you have no warnings you can just upgrade without fear, which is quite a nice way of doing it.

Re: ESLint v9.0

#49

Post by winrid »

erhaetherth wrote: post #48
winrid wrote: post #37

Earlier quoted context omitted.

Eslint released in 2013, so sounds about right. Even Java has had more major releases than that.

DataTables released in about 2008 ( https://cdn.datatables.net/1.0.0/js/jquery.dataTables.js ) and just released 2.0 on Feb 15 this year ( https://cdn.datatables.net/2.0.0/ ). No BC-breaks that I'm aware of in 16 years. Not saying every project can do it, but some of these ESLint changes seem rather unnecessary. React always adds warnings in 1 major release and then removes in the following major release, meaning if…

oh man, datatables, that takes me back.

I agree that the way React does things is preferable.

Post reply on HN