You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One thing I liked about eslint-loader is that it was run only on files in the graph module of the build. That is, if a file wasn't imported anywhere it was ignored.
With eslint-webpack-plugin I need to set up separate files/extensions configuration instead of simply relying on webpack to provide the files.
Feature Use Case
This is very useful whenever you don't have time to deal with files that are currently not part of the build.
My original assumption about this plugin was that it would lint files matched by 'files'/'context' when referenced by webpack... It is counter-intuitive to me that it would just run eslint on the context blindly... I get that's what the command line does, but the webpack build environment is more complex than that.
@jsg2021 My understanding of webpack internals is only very basic, but here are me thoughts. You need the plugin to get access to the full webpack api (and the advantages this plugin has over the loader), but you also need a mechanism to gather the relevant files, which happens to be pretty much what loaders do.
I mean, loaders are handled just by another plugin, so it makes sense you can do without it, but the reason I suggested using a loader is that it has already familiar established interface. It would also allow you to put the loader in between other loaders for some rarer use cases 🤔
Activity
jsg2021 commentedon Oct 12, 2020
I second this. I'm struggling to configure this plugin to match the efficacy of the loader.
jsg2021 commentedon Oct 12, 2020
My original assumption about this plugin was that it would lint files matched by 'files'/'context' when referenced by webpack... It is counter-intuitive to me that it would just run eslint on the context blindly... I get that's what the command line does, but the webpack build environment is more complex than that.
jsg2021 commentedon Oct 12, 2020
I'm researching how to do this. I'll open a PR if I find a way.
martinkadlec0 commentedon Oct 13, 2020
@jsg2021 My understanding of webpack internals is only very basic, but here are me thoughts. You need the plugin to get access to the full webpack api (and the advantages this plugin has over the loader), but you also need a mechanism to gather the relevant files, which happens to be pretty much what loaders do.
So perhaps the solution is to do something similar to what https://webpack.js.org/plugins/mini-css-extract-plugin/ does? That is having something like
ESLintPlugin.loaderthat you could put to rules to gather the files.Then you could establish reference access through
NormalModule.getCompilationHooks(compilation).loaderto pass the list of files to the plugin.I hope I am not pointing you to completely wrong direction though O:)
ricardogobbosouza commentedon Oct 14, 2020
@evilebottnawi
What is your opinion of having a loader inside this plugin? As @martinkadlec0 said
Ex:
ESLintPlugin.loaderalexander-akait commentedon Oct 14, 2020
We don't need loader, because we can do same logic inside plugin without a loader 😄
martinkadlec0 commentedon Oct 14, 2020
I mean, loaders are handled just by another plugin, so it makes sense you can do without it, but the reason I suggested using a loader is that it has already familiar established interface. It would also allow you to put the loader in between other loaders for some rarer use cases 🤔
jsg2021 commentedon Oct 14, 2020
Yeah, we can get the file names from events in just the Plug-in. We won't lint transformed code, so we don't need to use a loader. 😊
ricardogobbosouza commentedon Nov 4, 2020
Resolve on v2.2.0
Thanks @jsg2021