The immediate benefit here is now that all plugins used in a shared config are actually imported modules, so any host package that depends on the shared config, automatically has the right plugins. No more "multiple versions of an eslint plugin installed" problems.
Got reason to look into svelte-check, the #linting tool for #Svelte projects, and I must say – their approach is intriguing.
It’s essentially invoking Language Service (#lsp) diagnostics for all the files and using the diagnostics output from the TypeScript, HTML and CSS language services to determine if there's an error or not.
In other words: Mimicking how eg. VSCode does to report errors and warnings in its UI.
This is a very interesting approach compared to eg. @eslint parsers
I’m sorry… what?! Is shopify one jigantic monolith? #ESLint is far from performant (there’s a fantastic article about why that is), but even on million line codebases I’ve never seen it cross five minutes.
#JavaScript developers, do you think #ESLint should be a part of the build process?
I've seen quite a few projects use #Webpack and #Vite plugins to run ESLint during their build process. This both shows a huge error overlay when there are linting errors, and halts the build when building for production.
However, I never understood that, as linting does not really ensure validity of the code, but rather that it aligns to some stylistic rules.
To expand on the above, while #ESLint may prevent some errors (e.g. missed React dependency or such), it usually doesn't ensure that your code is valid and ready to run. Therefore, I think ESLint, just like #Prettier, should be only present as a plugin in your IDE and separate script in a package.
I would even go as far as to say that ESLint during the build is harmful and slows you down, as it can error for silly things like spaces, that do not affect the result of your code whatsoever.