eslint-webpack-plugin
eslint-webpack-plugin copied to clipboard
webpack-contrib
Futute + Perfomance
I was analyzing this plugin and doing some performance tests and I realized that some things should be refactored. Some proposed changes:
1. Not only parse files on graph
- Files
.d.tsare not linted https://github.com/webpack-contrib/eslint-webpack-plugin/issues/120 - If you want to ignore a file, use
.eslintignore
2. Remove option exclude
- Use
.eslintignore
3. Remove option threads
- Instead of increasing performance, it worsens dramatically
- With threads enabled, execution time increase by ~300% #137
- Waiting https://github.com/eslint/eslint/issues/3565
Not only parse files on graph
We can introduce special options - addinonalGlobs and pass them to eslint so developer can add files outside the graph
Remove option exclude
Sometimes you need to ignore some files related to build, but lint them normally, it is very exotic usage, exclude is a part of basic functional, maybe we can just improve docs and say you should prefer to use .eslintignore
Remove option threads
Yep, we need to improve multi threading API on webpack side and avoid to recreate threads
/cc @vankop
1. Not only parse files on graph
- Files
.d.tsare not linted Some files are ignored #120- If you want to ignore a file, use
.eslintignore
This begs the question "What is the purpose" of this plugin... I'm getting the sense that it has multiple reasons for multiple people. The "goal" of this project should be solidified before making these kinds of back/forth algorithm changes.
This plugin provides lint errors for (pick one):
- Files Used (in JS graph)
- All Project Files (synonymous with simply running
eslint, but reported through webpack)
Yep, we need to improve multi threading API on webpack side and avoid to recreate threads
🎉 Having webpack handle threads instead sounds like the real solution. It always bugged me that plugins have to handle that and deal with serialization and such on their own.😊
