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
Show an error for the misspelled toLowerCase (TS2551)
Ignore chars[0] being possibly undefined (TS2532)
You could specify one or multiple error codes in the brackets, comma separated.
π Motivating Example
When bringing code from other codebases with less strict rules, you sometimes would want to fix the typing issues over time. You could mark all of the failing lines with @ts-expect-error, to be fixed in subsequent code changes, but what if in the meantime someone makes an unrelated type mistake in one of those lines and it causes a run-time error?
Having the ability to specify what error you're expecting in those lines adds a layer of safety for a code you didn't really want to make unsafe.
π» Use Cases
1. What do you want to use this for?
To be more granular about what errors to expect.
2. What shortcomings exist with current approaches?
They allow for any error to exist in a given line.
3. What workarounds are you using in the meantime?
None
The text was updated successfully, but these errors were encountered:
RamonBalthazar
changed the title
Allow ts-expect-error to specify hexpected error code(s)
Allow ts-expect-error to specify the expected error code(s)
Apr 1, 2024
π Search Terms
"ts-expect-error"
β Viability Checklist
β Suggestion
Allow the
@ts-expect-error
annotation to be narrowed to one or multiple error codes.Example:
For the above code, TS would:
toLowerCase
(TS2551)chars[0]
being possibly undefined (TS2532)You could specify one or multiple error codes in the brackets, comma separated.
π Motivating Example
When bringing code from other codebases with less strict rules, you sometimes would want to fix the typing issues over time. You could mark all of the failing lines with
@ts-expect-error
, to be fixed in subsequent code changes, but what if in the meantime someone makes an unrelated type mistake in one of those lines and it causes a run-time error?Having the ability to specify what error you're expecting in those lines adds a layer of safety for a code you didn't really want to make unsafe.
π» Use Cases
1. What do you want to use this for?
To be more granular about what errors to expect.
2. What shortcomings exist with current approaches?
They allow for any error to exist in a given line.
3. What workarounds are you using in the meantime?
None
The text was updated successfully, but these errors were encountered: