You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
But wait - I hear you exclaim - why would you ever not want type-aware rules?
Well (for full disclosure) there is a catch; by including parserOptions.project in your config, you are essentially asking TypeScript to do a build of your project before ESLint can do its linting. For small projects this takes a negligible amount of time (a few seconds); for large projects, it can take longer (30s or more).
Most of our users are fine with this, as they think the power of type-aware static analysis is worth it. Additionally, most users primarily consume lint errors via IDE plugins which, through some caching magic, do not suffer the same penalties. This means that generally they usually only run a complete lint before a push, or via their CI, where the extra time really doesn't matter.
We strongly recommend you do use it, but the above information is included so that you can make your own, informed decision.
I suspect that the performance hit isn't significant, as noted. I'm in the "he power of type-aware static analysis is worth it" camp. We should add these rules.
The text was updated successfully, but these errors were encountered:
Some of rules available in the TypeScript plugin require type information:[1]
But a caveat exists:[2]
I suspect that the performance hit isn't significant, as noted. I'm in the "he power of type-aware static analysis is worth it" camp. We should add these rules.
The text was updated successfully, but these errors were encountered: