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
Maybe this request is out-of-scope for this project, but I think it would be a valuable addition.
Certain typescript-eslint rules are depending on having a typescript codebase that is using strict or at least strictNullChecks. For example this no-unnecessary-condition will work best if strictNullChecks are enabled.
Problem
If I run this plugin and start gradually migrating files by removing the strict ignore comment, and fixing all TS-errors, I would also like to remove unnecessary optional chaining calls or other condition that are not needed and only show up now after enabling strict mode.
Proposal
Enhance the script so that it can also add ignore comment for certain typescript-eslint rules to every file where it adds the //@ts-strict-ignore comment. An optional behavior that the user can select.
Examples
Comment block added when choosing to also ignore no-unnecessary-condition rule:
Comment block added when choosing to only ignore ts-strict errors (like it is now):
//@ts-strict-ignore
Pros
Codebase only needs to be touched once in a single commit
No extra script/manual process needed
Cons
Eslint and TypeScript are two different things. So this would widen the scope of the plugin which might not be desired.
Conclusion
Improving your codebase with typescript-eslint rules is considered good practice, but adding the rules to an already "problematic" ts-codebase is a pain, as you need to disable certain rules for many files (in my case 3000+ files). Bundling this action together with the plugin makes sense in my opinion, as typescript-eslint + ts-strict mode serve the same purpose, to make the code less error prone and also easier to read.
There seem to also be other typescript-eslint rules that depend on strict mode that would make sense to also disable for files where strict mode is also disabled, if teh users wishes so.
So maybe this feature should include more rules than only the one I gave as an example.
The text was updated successfully, but these errors were encountered:
Diesmon
changed the title
Add optional support for eslint rules that depend on strict mode
Add optional support for disabling typescript-eslint rules that depend on strict mode
Jul 16, 2024
Maybe this request is out-of-scope for this project, but I think it would be a valuable addition.
Certain typescript-eslint rules are depending on having a typescript codebase that is using
strict
or at leaststrictNullChecks
. For example this no-unnecessary-condition will work best ifstrictNullChecks
are enabled.Problem
If I run this plugin and start gradually migrating files by removing the strict ignore comment, and fixing all TS-errors, I would also like to remove unnecessary optional chaining calls or other condition that are not needed and only show up now after enabling strict mode.
Proposal
Enhance the script so that it can also add ignore comment for certain typescript-eslint rules to every file where it adds the
//@ts-strict-ignore
comment. An optional behavior that the user can select.Examples
Comment block added when choosing to also ignore no-unnecessary-condition rule:
Comment block added when choosing to only ignore ts-strict errors (like it is now):
Pros
Cons
Conclusion
Improving your codebase with typescript-eslint rules is considered good practice, but adding the rules to an already "problematic" ts-codebase is a pain, as you need to disable certain rules for many files (in my case 3000+ files). Bundling this action together with the plugin makes sense in my opinion, as typescript-eslint + ts-strict mode serve the same purpose, to make the code less error prone and also easier to read.
There seem to also be other typescript-eslint rules that depend on strict mode that would make sense to also disable for files where strict mode is also disabled, if teh users wishes so.
So maybe this feature should include more rules than only the one I gave as an example.
The text was updated successfully, but these errors were encountered: