11–20 of 49 posts
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.
Earlier quoted context omitted.
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?
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.
Earlier quoted context omitted.
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.
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.
I'm not sure what more you would want. It's a major version upgrade.
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.
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?
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.")
Earlier quoted context omitted.
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.
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.
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.
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?
Earlier quoted context omitted.
Check biome or oxlint. I don't think any of them support all the rules of eslint
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.
Earlier quoted context omitted.
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?
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
Certainly not. Breaking changes should still be avoided as much as possible.
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...