Type or lint error silenced instead of fixed
Type or lint errors silenced without a stated reason.
Why it matters
When the compiler or linter objects and the agent cannot see why, a suppression comment makes the build pass in one line. @ts-ignore, eslint-disable and # type: ignore are all common in training data, so they are a natural reach.
The objection is usually still true at runtime. A type error that was silenced becomes an undefined value or a wrong unit in production. A whole-file suppression is worse: it turns off checking for every line in the file, including code nobody touched, so future errors there are never reported.
Example
export function toInvoice(row: InvoiceRow): Invoice {
return {
id: row.id,
- total: row.total_cents / 100,
+ // @ts-ignore
+ total: row.total / 100,
currency: row.currency,
+ // eslint-disable-next-line @typescript-eslint/no-explicit-any
+ lines: (row as any).line_items,
};
}
What it detects
- New @ts-ignore, @ts-nocheck, @ts-expect-error, eslint-disable, # type: ignore, # noqa, pylint: disable, mypy: ignore, @SuppressWarnings, #pragma warning disable, //nolint and rubocop:disable in non-test code.
- Whole-file forms such as @ts-nocheck and a bare eslint-disable are rated higher.
- Not flagged: suppressions that state a reason (for example @ts-expect-error -- upstream typing bug, or eslint-disable with a rule name and a trailing comment), common Java @SuppressWarnings values such as unchecked, a suppression identical to one already in the file before the change, eslint-disable-next-line no-console, and anything in a test file.
What to do when it fires
Remove the suppression and read the error it was hiding. Most of the time it points at a real mismatch, such as a renamed field or a missing null check, that takes a line to fix.
If it genuinely cannot be fixed, for example a known bug in a library's types, narrow it to the one line and add the reason after it. The check accepts a suppression that says why.