7 ms·

ESLint v9.0

95 points by yeldarb 3y ago

DustinBrett 3y ago
I tried to migrate a few nights ago but gave up for now as it was too many changes. I will give it another go this week on a full stomach.
- mati365 3y ago
  Every upgrade of eslint is nightmare so nothing unusual
- Etheryte 3y ago
  So much of it is completely unnecessary breaking changes too. A good example is the config file, out of the box they no longer support using `.eslintrc.*` (you can still get this behavior back with a config flag), you're now expected to use `eslint.config.js` instead. So in short, they're just making every single project out there that relies on ESLint go and either add a flag or rename one file — for what?
  - steve_adams_86 3y ago
    Could it be a gradual move towards standardizing on js config files? Perhaps version 9 will only parse js configs, and this is a step towards that. Edit: Here’s some info about the gradual migration to flat config and deprecation of eslintrc: https://eslint.org/blog/2023/10/flat-config-rollout-plans/ https://eslint.org/blog/2023/10/flat-config-rollout-plans/ It seems like it’s been well thought out.
    - Etheryte 3y ago
      I'm not really seeing the argument, right now they're also pushing unnecessary work onto everyone who uses `.eslintr.js` which already is a js config file. Yes, it is a small amount of work to fix, but it still means you have to go and read the changes and figure out what the breaking changes are to begin with.
      - diob 3y ago
        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.
        Etheryte 3y ago
        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 line to stat two file names rather than one.
        steve_adams_86 3y ago
        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.
  - joshkel 3y ago
    There's a good write-up of the shortcomings that the new config file is trying to address here: https://eslint.org/blog/2022/08/new-config-system-part-2/ https://eslint.org/blog/2022/08/new-config-system-part-2/ E.g., faster and simpler file access from removing tree-walking for multiple `.eslintrc.*`; better defaults in line with modern JavaScript; better compatibility with modules and Node.js's own file loading. (And I suspect there's an element of "As long as we're having to introduce a breaking change, let's make it explicitly breaking by also changing the filename.")
  - chaorace 3y ago
    Err... isn't the whole point of a big number release to introduce big, breaking changes? All major projects have breaking changes... but only the nice ones do us the courtesy of saving breaking changes for major release milestones
    - DEADMINCE 3y ago
      > Err... isn't the whole point of a big number release to introduce big, breaking changes? Certainly not. Breaking changes should still be avoided as much as possible.
      - chaorace 3y ago
        So are you saying that now was not the time for a major release? Or are you saying that the major release had too many breaking changes?
        hesviiggvv 3y ago
        Option C: They were dumb breaking changes.
        8n4vidtmkvmk 3y ago
        Probably not. 9 is a big number. They're probably breaking too often. Should only break every few years.
        winrid 3y ago
        Eslint released in 2013, so sounds about right. Even Java has had more major releases than that.
        erhaetherth 2y ago
        DataTables released in about 2008 (https://cdn.datatables.net/1.0.0/js/jquery.dataTables.js 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/ 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.
  - stevula 3y ago
    > So in short, they're just making every single project out there that relies on ESLint go and either add a flag or rename one file Not every project. Many people switched to the .js format a long time ago since it’s more powerful. I understand the inconvenience though, especially since I don’t remember them deprecating the rc format when they introduced the js one.
    - Etheryte 3y ago
      This is not correct, even if you're using `.eslintrc.js`, you still have to go and rename it to `eslint.config.js`.
- kinow 3y ago
  I migrated a small project few hours ago and their docs covered most of what I needed. The linked post here has a link to https://eslint.org/docs/latest/use/migrate-to-9.0.0 https://eslint.org/docs/latest/use/migrate-to-9.0.0, but earlier today I used only this page: https://eslint.org/docs/latest/use/configure/migration-guide https://eslint.org/docs/latest/use/configure/migration-guide
- joshxyz 3y ago
  i usually wait at least a month on semver majors and at least a week on semver minors before i upgrade. its good.
- sunaookami 3y ago
  Updated a React Native project a month ago through 3 major versions and updating ESLint (to v8) was the most annoying and tedious part. I've just updated the main package and not the rules because something was broken constantly and it was spouting errors nonstop. Dealing with ESLint is the definition of "not fun". Ironic because it should make my life easier.
c-hendricks 3y ago
Loving the fact that their flat config compatibility package has 83% the number of weekly downloads compared to their main package. It was pretty obvious years ago that eslint messed up how package names are referenced in configs, and how they're resolved. Did it really require such a big change that affects the whole ecosystem? Microsoft seemed to have a pretty good solution with https://www.npmjs.com/package/@rushstack/eslint-patch https://www.npmjs.com/package/@rushstack/eslint-patch
deleted 3y ago
[deleted]
AbuAssar 3y ago
any ES linter written in rust?
- leosanchez 3y ago
  Check biome or oxlint. I don't think any of them support all the rules of eslint
  - qudat 3y ago
    I've been using biome since it was called rome. It's an excellent formatter / linter and reduces the configuration down to a single npm install and a single json file. I highly recommend people try it out and ditch the configuration nightmare that is eslint.
    - leosanchez 3y ago
      Performance is insane too
    - toastercat 3y ago
      It is great, just wish the install size wasn't so huge (40MB on Linux).
- HumanOstrich 3y ago
  Why does it have to be written in rust?
  - silverwind 3y ago
    Gotta go fast.
  - winrid 3y ago
    It doesn't seem like anyone is working on JS tooling in C++. Some projects used Go but switched to Rust... I guess the object lifetimes are probably pretty simple so it's a no brainer.
  - 3y ago
theogravity 3y ago
I've started using https://biomejs.dev/ 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 Standard JS. They go by their own rules, which is fine for a new project, but existing projects that use Standard JS or have custom rules will probably take time to convert over, and not all ESLint rules are supported either. https://github.com/biomejs/biome/discussions/2070#discussioncomment-8768550 https://github.com/biomejs/biome/discussions/2070#discussion...
- notnullorvoid 3y ago
  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.
  - atonse 3y ago
    I’m sure this isn’t an original idea but are any of these working on possibly translating JS based rules into rust or assembly and executing them faster?
    - notnullorvoid 3y ago
      You mean automatically translating existing eslint rules written in JS to rust? I haven't heard of any such plans, it would likely be really difficult. That being said they would still need a plugin system (probably using wasm as compile target for plugins) for this to be feasible.
  - Hasnep 3y ago
    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.
wdb 3y ago
Think I will wait until there is some sort of codemod available to switch to the flat config format :)
inkubus 3y ago
oh dear god, have mercy, how do i migrate to the new flat configuration format?
- HumanOstrich 3y ago
  It's a nightmare and you'll have to use compatibility shims for any plugins/extensions that haven't been updated yet.
jerrygoyal 3y ago
i spent several hours migrating it yesterday, when i fixed one issue another issue would come up and so on. for every issue i have to look through GitHub issues, google search, etc to resolve it as their migration guide is not comprehensive. I gave up eventually because i exhausted all options and couldn't fix issues. I think some plugins are not compatible with eslint v9 so it doesn't make sense to upgrade unless they do first. Some of the plugins haven't been updated in years so I'm not confident that i can migrate anytime soon.
- haburka 3y ago
  It seems very foolish to upgrade so immediately, why not wait for 9.0.2 or something? Let other people find the issues
mediumsmart 3y ago
fwiw still happy with jslint v2024.3.26

95 points by yeldarb 3y ago

I tried to migrate a few nights ago but gave up for now as it was too many changes. I will give it another go this week on a full stomach.

mati365 3y ago
Every upgrade of eslint is nightmare so nothing unusual
Etheryte 3y ago
So much of it is completely unnecessary breaking changes too. A good example is the config file, out of the box they no longer support using `.eslintrc.*` (you can still get this behavior back with a config flag), you're now expected to use `eslint.config.js` instead. So in short, they're just making every single project out there that relies on ESLint go and either add a flag or rename one file — for what?
- steve_adams_86 3y ago
  Could it be a gradual move towards standardizing on js config files? Perhaps version 9 will only parse js configs, and this is a step towards that. Edit: Here’s some info about the gradual migration to flat config and deprecation of eslintrc: https://eslint.org/blog/2023/10/flat-config-rollout-plans/ https://eslint.org/blog/2023/10/flat-config-rollout-plans/ It seems like it’s been well thought out.
  - Etheryte 3y ago
    I'm not really seeing the argument, right now they're also pushing unnecessary work onto everyone who uses `.eslintr.js` which already is a js config file. Yes, it is a small amount of work to fix, but it still means you have to go and read the changes and figure out what the breaking changes are to begin with.
    - diob 3y ago
      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.
      - Etheryte 3y ago
        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 line to stat two file names rather than one.
        steve_adams_86 3y ago
        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.
- joshkel 3y ago
  There's a good write-up of the shortcomings that the new config file is trying to address here: https://eslint.org/blog/2022/08/new-config-system-part-2/ https://eslint.org/blog/2022/08/new-config-system-part-2/ E.g., faster and simpler file access from removing tree-walking for multiple `.eslintrc.*`; better defaults in line with modern JavaScript; better compatibility with modules and Node.js's own file loading. (And I suspect there's an element of "As long as we're having to introduce a breaking change, let's make it explicitly breaking by also changing the filename.")
- chaorace 3y ago
  Err... isn't the whole point of a big number release to introduce big, breaking changes? All major projects have breaking changes... but only the nice ones do us the courtesy of saving breaking changes for major release milestones
  - DEADMINCE 3y ago
    > Err... isn't the whole point of a big number release to introduce big, breaking changes? Certainly not. Breaking changes should still be avoided as much as possible.
    - chaorace 3y ago
      So are you saying that now was not the time for a major release? Or are you saying that the major release had too many breaking changes?
      - hesviiggvv 3y ago
        Option C: They were dumb breaking changes.
      - 8n4vidtmkvmk 3y ago
        Probably not. 9 is a big number. They're probably breaking too often. Should only break every few years.
        winrid 3y ago
        Eslint released in 2013, so sounds about right. Even Java has had more major releases than that.
        erhaetherth 2y ago
        DataTables released in about 2008 (https://cdn.datatables.net/1.0.0/js/jquery.dataTables.js 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/ 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.
- stevula 3y ago
  > So in short, they're just making every single project out there that relies on ESLint go and either add a flag or rename one file Not every project. Many people switched to the .js format a long time ago since it’s more powerful. I understand the inconvenience though, especially since I don’t remember them deprecating the rc format when they introduced the js one.
  - Etheryte 3y ago
    This is not correct, even if you're using `.eslintrc.js`, you still have to go and rename it to `eslint.config.js`.
kinow 3y ago
I migrated a small project few hours ago and their docs covered most of what I needed. The linked post here has a link to https://eslint.org/docs/latest/use/migrate-to-9.0.0 https://eslint.org/docs/latest/use/migrate-to-9.0.0, but earlier today I used only this page: https://eslint.org/docs/latest/use/configure/migration-guide https://eslint.org/docs/latest/use/configure/migration-guide
joshxyz 3y ago
i usually wait at least a month on semver majors and at least a week on semver minors before i upgrade. its good.
sunaookami 3y ago
Updated a React Native project a month ago through 3 major versions and updating ESLint (to v8) was the most annoying and tedious part. I've just updated the main package and not the rules because something was broken constantly and it was spouting errors nonstop. Dealing with ESLint is the definition of "not fun". Ironic because it should make my life easier.

c-hendricks 3y ago

Loving the fact that their flat config compatibility package has 83% the number of weekly downloads compared to their main package. It was pretty obvious years ago that eslint messed up how package names are referenced in configs, and how they're resolved. Did it really require such a big change that affects the whole ecosystem? Microsoft seemed to have a pretty good solution with https://www.npmjs.com/package/@rushstack/eslint-patch https://www.npmjs.com/package/@rushstack/eslint-patch

deleted 3y ago

[deleted]

AbuAssar 3y ago

any ES linter written in rust?

leosanchez 3y ago
Check biome or oxlint. I don't think any of them support all the rules of eslint
- qudat 3y ago
  I've been using biome since it was called rome. It's an excellent formatter / linter and reduces the configuration down to a single npm install and a single json file. I highly recommend people try it out and ditch the configuration nightmare that is eslint.
  - leosanchez 3y ago
    Performance is insane too
  - toastercat 3y ago
    It is great, just wish the install size wasn't so huge (40MB on Linux).
HumanOstrich 3y ago
Why does it have to be written in rust?
- silverwind 3y ago
  Gotta go fast.
- winrid 3y ago
  It doesn't seem like anyone is working on JS tooling in C++. Some projects used Go but switched to Rust... I guess the object lifetimes are probably pretty simple so it's a no brainer.
- 3y ago

theogravity 3y ago

I've started using https://biomejs.dev/ 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 Standard JS. They go by their own rules, which is fine for a new project, but existing projects that use Standard JS or have custom rules will probably take time to convert over, and not all ESLint rules are supported either. https://github.com/biomejs/biome/discussions/2070#discussioncomment-8768550 https://github.com/biomejs/biome/discussions/2070#discussion...

notnullorvoid 3y ago
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.
- atonse 3y ago
  I’m sure this isn’t an original idea but are any of these working on possibly translating JS based rules into rust or assembly and executing them faster?
  - notnullorvoid 3y ago
    You mean automatically translating existing eslint rules written in JS to rust? I haven't heard of any such plans, it would likely be really difficult. That being said they would still need a plugin system (probably using wasm as compile target for plugins) for this to be feasible.
- Hasnep 3y ago
  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.

wdb 3y ago

Think I will wait until there is some sort of codemod available to switch to the flat config format :)

inkubus 3y ago

oh dear god, have mercy, how do i migrate to the new flat configuration format?

HumanOstrich 3y ago
It's a nightmare and you'll have to use compatibility shims for any plugins/extensions that haven't been updated yet.

jerrygoyal 3y ago

i spent several hours migrating it yesterday, when i fixed one issue another issue would come up and so on. for every issue i have to look through GitHub issues, google search, etc to resolve it as their migration guide is not comprehensive. I gave up eventually because i exhausted all options and couldn't fix issues. I think some plugins are not compatible with eslint v9 so it doesn't make sense to upgrade unless they do first. Some of the plugins haven't been updated in years so I'm not confident that i can migrate anytime soon.

haburka 3y ago
It seems very foolish to upgrade so immediately, why not wait for 9.0.2 or something? Let other people find the issues

mediumsmart 3y ago

fwiw still happy with jslint v2024.3.26