Harry Yates

I'm a web developer focused on TypeScript, React, and Three.js.

Disable Warnings and Enforce Code Quality with ESLint

Fri, 16th Feb 2024
Installing the Essentials

Here’s a quick command to get everything you need installed:

Post

This installs the ESLint parser and plugin for TypeScript, alongside ESLint and TypeScript themselves.

Understanding TypeScript Comments to Disable Warnings

TypeScript provides several comments that let you disable its type-checking in various scopes.

  • @ts-ignore: Tells TypeScript to turn a blind eye to the next line.
  • @ts-nocheck: Placing it at the top of a file is like putting up a "Do Not Disturb" sign for TypeScript, telling it to ignore the entire file.
  • @ts-expect-error: The thoughtful mediator, it tells TypeScript, "I'm expecting an error here; if you don't find one, then that's an issue."
Enforcing Best Practices

While the above comments can be incredibly useful, they can also be a double-edged sword, potentially leading to ignored errors and technical debt.

That's where the ESLint rule @typescript-eslint/ban-ts-comment comes into play. This rule allows you to enforce or restrict the use of these TypeScript directive comments.

Configuring ESLint to use this rule involves adding it to your .eslintrc configuration file. Here’s how you might set it up to discourage the use of @ts-ignore without a valid explanation in a comment:

Post

This setup ensures that any @ts-ignore comment must be accompanied by a description, encouraging developers to think twice before bypassing TypeScript's type-checking and to document their reasons for doing so.

Best Practices for a Clean Codebase

While disabling warnings can be handy in certain situations, it's always best to address the underlying issues whenever possible. Here are a few tips to keep in mind:

  • Use Directive Comments Sparingly: Reserve @ts-ignore and other similar comments for truly exceptional cases.
  • Document Your Decisions: Always leave a comment explaining why you're disabling type-checking for a specific line or file.
  • Refactor When Possible: Regularly revisit areas of your code that use these comments to see if the underlying issues can be resolved.