[HN Gopher] ESLint v9.0
___________________________________________________________________
ESLint v9.0
Author : yeldarb
Score : 76 points
Date : 2024-04-08 17:48 UTC (5 hours ago)
(HTM) web link (eslint.org)
(TXT) w3m dump (eslint.org)
| DustinBrett wrote:
| 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 wrote:
| Every upgrade of eslint is nightmare so nothing unusual
| Etheryte wrote:
| 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 wrote:
| 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/
|
| It seems like it's been well thought out.
| Etheryte wrote:
| 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 wrote:
| 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 wrote:
| 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.
| joshkel wrote:
| 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/
|
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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?
| kinow wrote:
| 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, but
| earlier today I used only this page:
| https://eslint.org/docs/latest/use/configure/migration-guide
| c-hendricks wrote:
| 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
| AbuAssar wrote:
| any ES linter written in rust?
| leosanchez wrote:
| Check biome or oxlint.
|
| I don't think any of them support all the rules of eslint
| qudat wrote:
| 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 wrote:
| Performance is insane too
| keb_ wrote:
| It is great, just wish the install size wasn't so huge
| (40MB on Linux).
| HumanOstrich wrote:
| Why does it have to be written in rust?
| theogravity wrote:
| 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 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#discussion...
| wdb wrote:
| Think I will wait until there is some sort of codemod available
| to switch to the flat config format :)
| inkubus wrote:
| oh dear god, have mercy, how do i migrate to the new flat
| configuration format?
| HumanOstrich wrote:
| It's a nightmare and you'll have to use compatibility shims for
| any plugins/extensions that haven't been updated yet.
___________________________________________________________________
(page generated 2024-04-08 23:01 UTC)