chore(eslint-plugin): defer type checks to improve rules performance#12296
Conversation
|
Thanks for the PR, @StyleShit! typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community. The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately. Thanks again! 🙏 Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently on https://opencollective.com/typescript-eslint. |
✅ Deploy Preview for typescript-eslint ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
View your CI Pipeline Execution ↗ for commit c917f08
☁️ Nx Cloud last updated this comment at |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #12296 +/- ##
=======================================
Coverage 86.82% 86.83%
=======================================
Files 513 513
Lines 16490 16500 +10
Branches 5141 5144 +3
=======================================
+ Hits 14317 14327 +10
Misses 1478 1478
Partials 695 695
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
JoshuaKGoldberg
left a comment
There was a problem hiding this comment.
Yesss this is great!!
I've long wondered if we could enforce this kind of preference with a lint rule. I don't think it's practically doable, so maybe an agent skill would be a better fit?
2df540c
into
typescript-eslint:main
|
An agent skill could be nice and useful. Should I raise a new issue for this? |
|
Yeah I think we'd want to think more holistically on that. Maybe we could provide agent rules as a part of the project! |

I was working on #11204, and realized that some rules might benefit from deferring the type checks after the AST structure checks.
I ran some benchmarks locally (M4 Pro, 24GB) against
packages/eslint-plugin:prefer-nullish-coalescingis about ~7% fasterno-base-to-stringis about ~4% fasterno-confusing-void-expressionis about ~32% fasterno-duplicate-type-constituentsis about ~2% fasterno-unsafe-returnis about ~3% fasterstrict-void-returnis about ~2% fasterRunning all rules is about ~1% faster (probably negligible, which is why it doesn't really help with #11204)
Some rules (i.e.,
require-array-sort-compare,prefer-regexp-exec) didn't show any performance gains from this change.I guess they will in codebases that actually violate them. Currently, they're basically skipping the type checks anyway in our codebase, thanks to selectors like
CallExpression[arguments.length=1] > MemberExpressiontogether with a member name check (.match,.sort, etc.).(Violating codebases might also show more performance gains for the rules in this PR, actually)
I'll open PRs for these rules if we go forward with this PR and decide that it's worth it.
Thanks to AI it was much faster to find areas where it was applicable