Skip to content

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

Merged
merged 4 commits into from
Aug 18, 2022

Conversation

jakebailey
Copy link
Member

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.

@jakebailey
Copy link
Member Author

Thinking about it, I can't imagine anyone calls the other tasks; I could just make all of them call the one lint task instead.

@andrewbranch
Copy link
Member

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.

@weswigham
Copy link
Member

🤷‍♀️ 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.

@jakebailey
Copy link
Member Author

jakebailey commented Aug 18, 2022

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 no-unnecessary-qualifier by adding a ts.Something into the compiler, and it complained, and that rule is only introduced in src/.eslintrc.

Copy link
Member

@weswigham weswigham left a 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.

@jakebailey
Copy link
Member Author

jakebailey commented Aug 18, 2022

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

@weswigham
Copy link
Member

I only run gulp lint, personally.

@DanielRosenwasser
Copy link
Member

I run gulp runtests-parallel and when the tests start passing I stage my changes, commit, push, and then see lint failures immediately after pushing or in CI, personally.

@jakebailey
Copy link
Member Author

Cool. I'll just delete the other sub-tasks and if someone ends up wanting them, they are easy enough to restore.

@jakebailey jakebailey merged commit df25b77 into microsoft:main Aug 18, 2022
@jakebailey jakebailey deleted the eslint-root branch August 18, 2022 18:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Author: Team For Uncommitted Bug PR for untriaged, rejected, closed or missing bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants