Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
davidgomes opened this issue Jan 13, 2019 · 10 comments
Closed

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

davidgomes opened this issue Jan 13, 2019 · 10 comments

Comments

@davidgomes
Copy link

@davidgomes davidgomes commented Jan 13, 2019

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
Copy link
Contributor

@rictic rictic commented Jan 14, 2019

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
Copy link

@kolodny kolodny commented Jan 15, 2019

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
Copy link
Member

@RyanCavanaugh RyanCavanaugh commented Jan 15, 2019

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
Copy link

@Mouvedia Mouvedia commented Jan 15, 2019

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

@chrisblossom
Copy link

@chrisblossom chrisblossom commented Jan 15, 2019

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
Copy link

@TSMMark TSMMark commented Jan 16, 2019

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
Copy link

@eps1lon eps1lon commented Jan 16, 2019

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

@alesn
Copy link

@alesn alesn commented Mar 28, 2019

@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
Copy link
Member

@RyanCavanaugh RyanCavanaugh commented Aug 19, 2019

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
Copy link

@bradfordlemley bradfordlemley commented Sep 8, 2019

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

bbugh added a commit to bbugh/vue-apollo that referenced this issue Dec 22, 2019
There were a lot of TypeScript edge cases, where calling functions with
certain argument options would result in `any` being expressed as a
type, or where the variables/options were not strictly requiring the
desired inputs.

This adds TypeScript function overloads for all hook edge cases so that
all types are correct. This does not change any behavior.

This also adds almost complete coverage for types, excepting the cases
where `strict` is required, or where a failure is expected, which
TypeScript does not currently support. See:
microsoft/TypeScript#29394
Akryum added a commit to vuejs/vue-apollo that referenced this issue Jan 10, 2020
…ng overloads (#895)

* fix: add apollo-composable type overloads + tests

There were a lot of TypeScript edge cases, where calling functions with
certain argument options would result in `any` being expressed as a
type, or where the variables/options were not strictly requiring the
desired inputs.

This adds TypeScript function overloads for all hook edge cases so that
all types are correct. This does not change any behavior.

This also adds almost complete coverage for types, excepting the cases
where `strict` is required, or where a failure is expected, which
TypeScript does not currently support. See:
microsoft/TypeScript#29394

* chore: run type tests on prepublish

* chore: code style
@orta orta closed this in #36014 Mar 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.