Big update! The #ESLint team is expanding its horizons by adding official support for the #CSS language, alongside JSON and Markdown linting.

Get all the details on #InfoQ https://bit.ly/4kTPMyW

> we’ve reached a saturation point where the API surface is mostly settled, and everyone just wants “the same thing, but faster.” Hence the explosion of new tools that are nearly drop-in replacements for existing ones: #Rolldown for #Rollup, #Oxlint for #ESLint, #Biome for #Prettier, etc.

https://nolanlawson.com/2024/10/20/why-im-skeptical-of-rewriting-javascript-tools-in-faster-languages/

Silly `eslint` question for the #JavaScript gurus out there, is there a flag or configuration setting I can pass to `eslint` to check a file altered with `eslint --fix` (`prettier` plug-in is involved) to ensure it remains syntactically valid?

I've got a problem where after running `eslint --fix` on a file, the result goes from "working but not conform-ant with style rules" to "conform-ant but now has syntax errors and doesn't work".

e.g. finding `);` in the middle of a function after it's "fixed" a file.

I figure if the linter can run the prettier, then check the resulting file is still valid JS (syntactically correct), that'd catch a lot of issues.

99 dependencies and they're all @eslint

Hold up a minute! ESLint changed their config files? I can't use .eslintrc anymore?

Oh hell, there is new work on the horizon. TypeScript #ESLint v6 just came out (https://typescript-eslint.io/blog/announcing-typescript-eslint-v6/), but ESLint 9 not yet, which adds a new config format (https://eslint.org/docs/latest/use/configure/configuration-files-new), and everything is going to be broken when it comes to code style tooling for the next 12 months, I fear.
#JavaScript