Don't try and outsmart the linter

If the linter (e.g. eslint) complains at you, try and fix the underlying issue before using a supression statement.

If it's complaining at you, it's warning you about what it thinks is bad code - which we're expected to actually fix, and not just ignore :)

You can always google the rule (e.g. no-unused-vars) to learn more about why it's complaining, and how to resolve.

If you decide that in your case, the rule doesn't apply and there's a legimate reason for supressing - that's totally cool! Be sure to follow give-reason-for-suppression :D

More Tips

assert-type-conditions: Use assertions for possibly null values
avoid-network-in-unit-tests: Avoid making network requests in unit tests
chain-errors: Chain custom errors to preserve stack traces
custom-errors: Use custom errors for error handling and control flow
dont-outsmart-linter: Don't try and outsmart the linter
dont-outsmart-typechecker: Don't try and outsmart the typechecker
dont-pass-huge-objects: Don't pass huge monolithic objects to helper functions
file-reading-race-condition: Don't check if a file exists before reading it
give-reason-for-suppression: Give a reason when using suppression statements
limit-logic-in-try-block: Limit the amount of logic in a try/catch block
limit-what-you-catch: Limit what errors you catch in a try/catch block
provide-typechecker-errors: Copy and paste error messages from the typechecker when using suppression statements
put-units-in-names: Put units in names
return-early: Return early from a function when checking initial conditions
use-permalinks: Link to code and docs with permalinks where possible

Edit dont-outsmart-linter.md on GitHub.