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)

[tom-spalding]

This would be extremely useful for people who are using typechecking via the tslint/eslint plugins (https://github.com/typescript-eslint/typescript-eslint) or using tsc on Javascripts, but are not actually using Typescript. We have a lot of generic errors that just aren't practical to deal with and cant turn them off unless we can reference the shortname. Or there are errors on perfectly good Javascripts that we won't be changing.

Example 2339 shortname found in https://github.com/microsoft/TypeScript/blob/v3.6.3/src/compiler/diagnosticMessages.json#L1199-L1202.

made a similar issue in typescript-eslint/typescript-eslint#2273.

[TedDriggs]

@RyanCavanaugh our product embeds V8 to let customers write event handlers. We wrap their code in an IIFE, which means if (!HTTP.userAgent) return; in the module root is valid code for our use-case.

We've written code to generate a .d.ts file for our API so we get autocompletion and type-checking in the browser thanks to Monaco. We deal with the early-return diagnostic by hiding it from Monaco after matching on code and message.

We'd like to let people download the .d.ts file and a jsconfig.json so they can work on their handlers offline. However, we can't hide specific diagnostics in the customer's editor for them. That leaves us in an unfortunate situation where writing idiomatic handler code would clog up the error log because TS doesn't know enough about where this code will be used.

[jespertheend]

An import path cannot end with a '.ts' extension. Consider importing '.js' instead. ts(2691)

See #37582. I suppose this would break compilation. But I'm using tsc with --noEmit only.

[egasimus]

An import path cannot end with a '.ts' extension. Consider importing '.js' instead. ts(2691)

See #37582. I suppose this would break compilation. But I'm using tsc with --noEmit only.

And the opposite of that:

TS2835: Relative import paths need explicit file extensions in EcmaScript imports when '--moduleResolution' is 'node16' or 'nodenext'

Yeah, no. I aint doing that, I've got my own postprocessing step that fixes the invalid ESM imports/exports generated by TypeScript (seriously folks?) - and I'd very much like TSC to shut up about this. So how about adding a flag that just lets us ignore errors by number and being done with it? Expecting valid reasons here, and no, protecting developers from themselves is not a valid reason.

TypeScript is full of these cases where it forbids certain completely valid behaviors for no benefit. It feels like being nudged into Microsoft-approved workflows, patterns, and ways of reasoning. Not only is this ruining the JavaScript experience for me big time (and no, I don't have the option to not use TypeScript) -- it's actively harmful for new developers who'll have an even more difficult time figuring out what's going on. This is the most frustrating part of using TypeScript, and I consider it user-hostile behavior on par with Microsoft's previous efforts - hence my unapologetically irate tone, which accurately reflects my frame of mind when dealing with TypeScript.

[Amatewasu]

This feature would be super useful when we have a TypeScript bug and we don't have any fix yet.

(for example: #45149 ; pmndrs/drei#823 )

[aliflux-omo]

Hi. Is there any update on this feature? It's super helpful when an external dependency has an error

[AskYous]

March 12... we're suffering from this error too.

[knackstedt]

I'm also going to bump this. I want to disable TS checking of a depenency I use that doesn't publish a compiled dist, but I leverage their source TS files, and they have some TS7030 errors and TS7029 warnings that are really frustrating as the code is fine, but their TSConfig is ignored and I have no good way to get around this otherwise.

[anukem]

Surprised this hasn't been implemented yet. I'm working in a codebase with over 1400+ errors, and as part of code cleanup, I want a way to allow engineers to focus on specific errors, so they aren't context switching going through the massive list of issues. Additionally, it would be helpful to help prioritize which errors show up the most.

[bworline]

@RyanCavanaugh another use case for you:

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?

I'm interested in suppressing errors I can't do anything about. I am writing a new package X that is consuming an external npm package Y. Within package Y there is a typescript error. I don't control that code, so I can't do anything to suppress it. Ignoring a particular error id (or even everything) under node_modules/Y would be helpful.