The @ts-ignore Directive in TypeScript
The as
and non-null assertion operators are useful for suppressing TypeScript errors in code.
However, there's another way to suppress errors: the @ts-ignore
directive.
The @ts-ignore
directive is similar to how linters like ESLint allow you to disable rules for specific lines of code.
Cons
Transcript
00:00 we've been looking at as, we've been looking at the non-null assertion operator. In other words, we've been looking at ways that you can suppress TypeScript and say, I know more than you. And you might be thinking like, okay, I've used ESLint before, let's say, or a linter. There's usually a way in a linter where you can suppress errors
00:18 that are happening on the next line down. So ESLint has ESLint disable next line. And TypeScript has something similar. We have a handle form data function here, which takes in an E of submit events. We've seen this set up before. And then on E, we're passing E.target to new form data. But this is erroring because event target
00:36 is not assignable to parameter of type HTML form elements. Okay, so this is a little bit annoying for us. And we've tackled this error before by saying E.target as any. This basically makes E.target kind of inferred as any in that spot. And it means that we can then pass it into form data because any is assignable to anything.
00:56 This of course is not necessarily perfectly type safe, but it's a way to proceed. There is a way though, that's a little bit uglier and a little bit less good, I'd say, of doing this, which is on the line above, we can say at TS ignore. And that ignores all of the errors on the next line down.
01:16 Now, you might think this is good because, okay, we've got rid of our error, fantastic. But we can now say E.target if we want to. We could call this new F data if we want. Can we even use like a, no, we can't. There are some things that will catch, like actual syntax errors will still be caught, but any type errors will not be caught.
01:36 So new F data, if we were to uncomment this, cannot find name F data, did you mean data? So this basically means that TS ignore just targets everything in the next line. So you think about this, there is a variable name, there is a new call here to something that may or may not exist.
01:55 And there's E.something here. We can make this a little bit more precise by removing that and saying new form data. And then inside the parentheses using TS ignore just on E.target. But even there, we can spell E wrong. We can say event, for instance. And this is just really, really dangerous
02:14 and just not a very pleasant thing to use. Because if we say E.target, let's say as any inside here, then we're still going to get like all of the actual type checking on things that we're accessing. So here, we cannot find name and E.target,
02:31 we're still going to get errors on that one too. So TS ignore is kind of like a less precise version of as any. You will sometimes see this used out in the wild, like if you're doing some really complex type logic, you'll sometimes see this, but pretty much always there's a way around this.
02:49 And I really don't think I can recommend ever using TS ignore in your application code bases, because it's just too imprecise. As any, if needed, is already fairly unsafe. And TS ignore is just kind of like taking that unsafety that you get with as any and using it like Thor's hammer
03:08 just on your code base and just breaking everything. So TS ignore, I would say don't use it almost ever.