-
Notifications
You must be signed in to change notification settings - Fork 12.9k
Run eslint at root, rather than on src and scripts individually #50327
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
Conversation
Thinking about it, I can't imagine anyone calls the other tasks; I could just make all of them call the one |
I have a vague recollection that maybe these were separated in order to have separate cache files? But it seems like separating scripts (very small) from compiler (very large) would have minimal utility on that front. I might be thinking of something else. @weswigham probably remembers. |
🤷♀️ That's the best answer I have, too. Iirc, I think they had different rules enabled, too, since we didn't have most semantic lints enabled for scripts, but did for the compiler at some point. |
They do have different rules enabled, but as far as I can tell, eslint fully understands nested configurations by looking up the file system tree; I tested things out by introducing lint errors in both places, and it behaved as expected. e.g., I triggered |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably also still separate tasks from when it was tslint, which, afaik, only supported one config per invocation.
Ah, makes sense. Any opinions on whether or not I just delete the old tasks? I'm not sure anyone is running them directly. Maybe it's useful to run on just the scripts or something, but I don't quite know if that matters given you can see lint errors in your editor pretty readily... |
I only run |
I run |
Cool. I'll just delete the other sub-tasks and if someone ends up wanting them, they are easy enough to restore. |
This is slightly faster (a few seconds) in my testing (average of 5 runs, without cache).
It'd probably be best to delete the individual tasks, but I don't know who depends on those directly besides our
package.json
scripts.