TypeScript: tsconfig - Ignore errors by ids

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.

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/

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.

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

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

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

(for example: https://github.com/microsoft/TypeScript/issues/45149 ; https://github.com/pmndrs/drei/issues/823 )

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.

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

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.

@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.

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.

@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 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)

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 😃

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.

March 12… we’re suffering from this error too.

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

See https://github.com/microsoft/TypeScript/issues/37582. I suppose this would break compilation. But I’m using tsc with --noEmit only.

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.