ts-ignore should error if next line is not an error

[davidgomes]

http://www.typescriptlang.org/play/#src=%2F%2F%20%40ts-ignore%0D%0Aconst%20a%3A%20number%20%3D%205%3B

In the example above, the @ts-ignore line should error because there is no TypeScript error to be ignored. This is the same behavior as Flow's suppress_comment feature.

Alternatively, if you want to maintain this behavior, consider creating a @ts-expect-error.

[rictic]

This is something that I often want when writing trickier library functions, and in DefinitelyTyped typings.

In the same way that you want to test that some inputs fail at runtime in your tests, it's desirable to be able to write tests that certain code will produce an error when compiled.

At present it's as though there's no way to assert that a function throws.

[kolodny]

This is very important for library authors to ensure that their types are valid. I've had to do some nasty stuff to ensure that fact without this feature

[RyanCavanaugh]

This is the intended behavior because one of the scenarios for ts-ignore is to allow the same code to work across multiple TS versions which may have slight differences between them.

https://github.com/Microsoft/dtslint supports "expecting" errors if that's your scenario.

It'd be good to hear more from you about what you'd like to use the different behavior for.

[Mouvedia]

This is about parity with Flow's $ExpectError.
$ExpectError has also been adopted by typings-checker.

[chrisblossom]

This would be very helpful/great for longterm maintenance of a project. Flow already can do this on their $FlowFixMe suppressions, and eslint can do this via the command line flag --report-unused-disable-directives or using plugin-eslint-comments/rules/no-unused-disable as well.

This is the intended behavior because one of the scenarios for ts-ignore is to allow the same code to work across multiple TS versions which may have slight differences between them.

I think this option should be opt-in behind a configuration flag so this shouldn't be an issue.

This would be even better in-combination with #19139 / #21197.

[TSMMark]

My team is considering migrating to TS from Flow in 2019. We would love to see the functionality of $ExpectError in TS in order to continue to unit test our typings ❤️

[eps1lon]

@TSMMark You can do this with tslint and the expect rule from dtslint.

[alesn]

@RyanCavanaugh Understood from your comment why it is intentional that @ts-ignore does not cause an error when it is not "actively ignoring found error" (to support various versions of TypeScript, which might differ in whether or not they find an error there).

I am also now moving from Flow to Typescript; new to Typescript. A really working $ExpectError would be good to have ($ExpectType could be nice as well). I have tried to make dtslint work on a code-base (couldn't). I could assume it might work for type tests in .d.ts files that contain purely type definitions / type tests and don't import anything. However, I couldn't make it work with files, where it is actually needed to test $ExpectError, like in unit tests, where types would be tested including type inference in code, etc. Dtslint would bail out with a heap of errors that it didn't like syntax in some node_modules (it wasn't possible to exclude those). Another reason why I didn't dig deeper in this is that I understand dtslint is built on top of tslint and from news I've read about the official switch from TSLint to ESLint for Typescript, so not sure if dtslint would keep working with new Typescript or not even if it worked now.

A functional solution to be able to use $ExpectError in regular Typescript code (not only in definition files, where possibilities are limited) would be good to have - whether it would be directly in tsc or in a supported linter. This is something that works in Flow as described above

[RyanCavanaugh]

Accepting PRs for the form

// @ts-expect-error
const nope: string = 42;

Note that this is a substantially different feature implementation-wise from ts-ignore because TS will need to proactively find these comments and track whether or not they've suppressed an error by the time checking ends. We'll be watching performance closely on this PR so keep that in mind.

[bradfordlemley]

Suggest updating the title of this issue to "Type correctness verification via @ts-expect-error" or something like that.