eslint-webpack-plugin icon indicating copy to clipboard operation
eslint-webpack-plugin copied to clipboard

Some files are ignored

Open NZhuravlev opened this issue 3 years ago • 9 comments

  • Operating System: macOS Big Sur 11.5.2
  • Node Version: v14.17.6
  • NPM Version: 6.14.15
  • webpack Version: 4.46.0
  • eslint-webpack-plugin Version: 2.5.4

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.

NZhuravlev avatar Sep 28 '21 16:09 NZhuravlev

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.

rklos avatar Oct 19 '21 18:10 rklos

@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?

ricardogobbosouza avatar Oct 26 '21 13:10 ricardogobbosouza

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

alexander-akait avatar Oct 26 '21 13:10 alexander-akait

An option to lint files out of graphic should be interesting

ricardogobbosouza avatar Oct 26 '21 13:10 ricardogobbosouza

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?

jsg2021 avatar Oct 26 '21 13:10 jsg2021

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.

NZhuravlev avatar Oct 26 '21 13:10 NZhuravlev

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?

ricardogobbosouza avatar Oct 26 '21 15:10 ricardogobbosouza

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

alexander-akait avatar Oct 26 '21 15:10 alexander-akait

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.

riteshjagga avatar Apr 22 '22 17:04 riteshjagga