webpack-contrib / eslint-webpack-plugin

A ESLint plugin for webpack
MIT License
257 stars 49 forks source link

Some files are ignored #120

Closed NZhuravlev closed 5 months ago

NZhuravlev commented 3 years ago

Expected Behavior

Errors in all the specified folders should be reported.

Actual Behavior

With either

new ESLintPlugin({
    files: ["src", "api-examples"],
    extensions: [".ts"],
    emitWarning: true,
    emitError: true,
    failOnWarning: true,
}),

or

new ESLintPlugin({
    extensions: [".ts"],
    emitWarning: true,
    emitError: true,
    failOnWarning: true,
}),

errors in the api-examples (one of the folders in the project) are not getting reported.

Code

eslintignore:

npm-api/*

.eslintrc.js:

module.exports = {
    "parser": "@typescript-eslint/parser",
    "parserOptions": {
        "ecmaVersion": 6,
        "sourceType": "module",
        "project": "./tsconfig.eslint.json",
        "tsconfigRootDir": __dirname
    },
...

tsconfig.eslint.json:

{
        ...
    "include": [
        "src/**/*.ts",
        "api-examples/**/*.ts"
    ],
    "exclude": [
        "npm-api"
    ]
}

How Do We Reproduce?

If I were to guess it's about setting up a ts project with similar rules. api-examples folder files here are not used by webpack while compiling - it might be a problem. The documentation says it's possible to lint files outside the compiler context.

rklos commented 2 years ago

I have the same problem. All of my .d.ts files are ignored even if they're imported in my runtime code. Repro repo: https://github.com/rklos/nuxtjs-eslint-module-issue-example IFooBar should be reported as wrong name of interface. I'm using nuxtjs in this project and it uses eslint-webpack-plugin at version "^2.4.1".

Running eslint directly via CLI command reports all errors without exceptions.

ricardogobbosouza commented 2 years ago

@NZhuravlev thanks for reporting and @rklos thanks for example.

For some reason the webpack is not included the d.ts files on the graph.

@alexander-akait, @jsg2021 any idea?

alexander-akait commented 2 years ago

Oh, ts-loader here, they are emitted as assets, i.e. out of graph (to be honestly I think it is expected, we don't use .d.ts in graph), in theory we can lint emitted assets, but it should be under option

ricardogobbosouza commented 2 years ago

An option to lint files out of graphic should be interesting

jsg2021 commented 2 years ago

At that point, you should just use eslint directly and run it on your files via cli/watch... kinda out of scope for this plugin wouldn't you think?

NZhuravlev commented 2 years ago

Yeah, then it's just easier to lint everything with eslint directly, otherwise, you need 2 different configurations to do more or less the same job. I can't say whether it's in the scope of the plugin but IMO it should be clarified in the documentation.

ricardogobbosouza commented 2 years ago

Having an option to lint some files out of graph, ino case of .d.ts files make sense even if it's out of scope, this can avoid duplicate settings. @alexander-akait wdyt?

alexander-akait commented 2 years ago

Honestly - yes, I think even more linting and formatting are out of scope bundling, we have these package only because it is still popular, but I don't want to sacrifice perf, just setup CI and run eslint/stylelint/prettier/etc on CI before merge, just my opinion

riteshjagga commented 2 years ago

It would be nice to have them in the scope of the plugin. We have a case where our spec files are in different directory than the src files but would like to have spec files follow consistent styling too.

Eslint can be directly used to lint multiple directories (src, spec or any other directories) but that would mean that we'll need to connect the eslint failures to fail the webpack compilation too somehow, which I do not know how to do it, at the time of writing.

This plugin brings the benefit of failing the webpack compilation (which was one of the big reason it was chosen for our project) in case of any linting errors and developers are then enforced by the means of errors to fix them which brings consistent styling, which means less reviewer efforts on the code reviews.

We needed it before code changes could go to CI to save the turn around time.