tsconfig - Ignore errors by ids

[sancarn]

I know that all errors in TypeScript are optional, it'd be nice if we could declare which error ids we want to ignore.

I.E. In the tsconfig.json:

{
   "compilerOptions":{
      "ignoreErrors":[2403,2686,...]
   }
}

The reason I say this is because a lot of these errors are just irratating... Like the error:

'L' refers to a UMD global, but the current file is a module. Consider adding an import instead.

This isn't an actual type error. It's a code style suggestion, and is entirely subjective unlike invalid type errors. I find many little 'errors' like this and they are deeply frustrating, as they just fill the error log with rubbish... Allow us to define which error ids we want to ignore, and this won't happen.

[pablobirukov]

It would be nice to have this functionality similar to -nowarn in C#. However, I find it useful to specify a paths where certain errors are ignored.

@sancarn, you may consider using https://github.com/evolution-gaming/tsc-silent.

Once installed it supposed to replace tsc

tsc-silent -p tsconfig.json --suppress 7017@src/js/ 2322,2339,2344@/src/legacy/

[milesj]

Yes please! This would be especially helpful for test files where the tests explicitly test invalid types or access for edge cases. It gets annoying having to add ts-ignore all over test files.

[RyanCavanaugh]

We have a ton of flags to suppress certain errors (the one you mention, we are accepting PRs to add a flag for). What errors are people interested in suppressing, and why?

[milesj]

The biggest one for me is disabling access errors of protected/private members. I prefer granular unit testing over integration testing, so I primarily test those methods directly, which requires me ts-ignoring all call sites.

Here's an example: https://github.com/milesj/aesthetic/blob/master/packages/core/tests/Aesthetic.test.tsx#L107

[sancarn]

@RyanCavanaugh I don't understand why you it's better to restrict the errors to a certain subset of pre-existing flags... Literally customisation is key in my opinion. The more customisable typescript is, the better imo.

I tend to agree with @pablobirukov, this is especially helpful if you can specify certain file paths (or file patterns) because sometimes you are required to call private methods in a specific file, but would like them to be inaccessible everywhere else.

[RyanCavanaugh]

Error numbers aren't 100% guaranteed to be stable from release to release. For example, today two different incorrect things might produce the same error, but it'd be better if they produces two different errors for clarity - this would break ~half the people who ignored the original errors based on number. So if there are things which we can just name with a flag and turn off, that's sometimes preferable.

[dcodeIO]

Over at AssemblyScript I could also use an option to disable specific errors. The use case here is that we had to stretch the spec a bit, for example to allow decorators (which are more like compiler annotations in AS) to appear on functions and globals as well to do different things, like always @inline a function, compile a global @lazyly or wire a @builtin to the compiler. Currently, there are like 500 // @ts-ignores to work around this. This certainly is rather for (syntax highlighting) compatibility with a compiler that isn't really tsc, and I'd understand if you'd consider this an invalid use case therefore. Nonetheless, it'd make my little WASM adventure a lot more convenient :)

[SSPJ]

The biggest use case for me (and perhaps there is already a compiler flag which does this but I read the documentation carefully and couldn't find one) is that when I am developing, I want to put broken code in my file and compile it and look at the results. It slows my development process to a frustrating crawl when I add:

const responseData = await SomeApi.someEndpoint({data: queryParameters});
console.log(responseData.count);

and I get

TS6133: 'responseData' is declared but its value is never read.
ℹ ｢wdm｣: Failed to compile.

All I want at that specific moment is to see the count. I waste enormous amounts of time on these non-errors. A real world analogy is the requirement that garages keep their floors clean: of course a professional mechanic will regularly sweep up shavings and mop up oil, but he isn't going to stop work in the middle of an oil change because two drops of oil got onto the shop floor.

(I am reasonably sure that someone will be tempted to point out that I can test API calls in the console. Don't.)

I would also posit that error numbers should generally be considered part of a stable contract. Once an error number is assigned, it should always refer to the same error, because people will use it for years in google searches and support tickets and so on. That doesn't mean new errors can't be added or old ones retired. It just means that error numbers should never be reassigned or change meaning in any way.

[deenem]

I'm using the OpenAPI code generator (https://github.com/OpenAPITools/openapi-generator) to generate typescript-angular code. Because it's generated code and because it's a third party generator, I want it to be transpiled without any error checking at all.
The main error that comes up is TS6133, it's a variable that is generated and not used all the time. It's just generated in case it might be used later.
But essentially, an option to say ' transpile these files to JS without looking for errors' would be nice

[caleb15]

We are migrating to typescript at 15Five and it would be useful to disable individual errors to be able to do a gradual migration.

Note that the idea of blacklisting specific errors in a type-checker is not a new one - pytype already does it.

[pablobirukov]

@caleb15 http://birukov.me/blog/all/tsc-silent.html

[matthewrobertson]

@RyanCavanaugh one example of an error that my team would like to opt-out of is:

TS2352: Conversion of type 'Foo' to type 'Bar' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert the expression to 'unknown' first.

Our team is working with a bunch of code that was converted to Typescript. We know the casts are correct, but the type checker doesn't always believe us. Seems like there have been other requests to disable this one (eg #28067)