Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Futute + Perfomance #143

Open
ricardogobbosouza opened this issue Feb 24, 2022 · 3 comments
Open

Futute + Perfomance #143

ricardogobbosouza opened this issue Feb 24, 2022 · 3 comments

Comments

@ricardogobbosouza
Copy link
Collaborator

ricardogobbosouza commented Feb 24, 2022

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

2. Remove option exclude

  • Use .eslintignore

3. Remove option threads

@ricardogobbosouza
Copy link
Collaborator Author

@alexander-akait your opinion is always welcome 😄

@alexander-akait
Copy link
Member

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

@jsg2021
Copy link
Contributor

jsg2021 commented Feb 25, 2022

1. Not only parse files on graph

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.😊

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants