Repository navigation
tsconfig - Ignore errors by ids #29950
Description
Activity
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 (@sancarn), you may consider using https://github.com/evolution-gaming/tsc-silent.
Once installed it supposed to replace
tsctsc-silent -p tsconfig.json --suppress 7017@src/js/ 2322,2339,2344@/src/legacy/
Reacted by Sancarn, Matthew Erwin, Caleb Collins-Parks, Laszlo Kocsis, Chris Harrington, Jesper van den Ende, ૮༼⚆︿⚆༽つ, diep-it-dn and Kevin CameronYes 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.
Reacted by Jesper van den EndeWe 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?
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
Ryan Cavanaugh (@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 Pavel Birukov (@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.
Reacted by dcodeIO, Jesper van den Ende and JacobError 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.
Reacted by Sancarn, Benjamin Rood and Yumin ChenReacted by Ahmed Hassanein, Yumin Chen and Zac WinterOver 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
@inlinea function, compile a global@lazyly or wire a@builtinto 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 :)Reacted by Max Graey and Aaron TurnerThe 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.
Reacted by Benjamin Rood, Dakinnie, Ahmed Hassanein, Philipp Uhl, Adam Spiers and Stein StrindhaugI'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 niceReacted by Benjamin Rood, Eugene Lakhanski, mpilnan, Yousef Shanawany and AlexanderKrasovskiyWe 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.
Reacted by dcodeIO, Vašek Purchart and Tom Spalding- Reacted by Almenon, Wim Lewis, Vlad Moyseenko, Radics Laszlo, Ahmed Hassanein and Adam Spiers
Ryan Cavanaugh (@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 microsoft/vscode#28067)
Reacted by Duke Dorje, Sarin Rajendran and AlexanderKrasovskiyThis would be extremely useful for people who are using typechecking via the tslint/eslint plugins (https://github.com/typescript-eslint/typescript-eslint) or using
tscon 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
2339shortname 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.
Ryan Cavanaugh (@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.tsfile 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.tsfile and ajsconfig.jsonso 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.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
--noEmitonly.Reacted by JacobAn import path cannot end with a '.ts' extension. Consider importing '.js' instead. ts(2691)See microsoft/vscode#37582. I suppose this would break compilation. But I'm using tsc with
--noEmitonly.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.
Reacted by Tom Spalding, Liv, MinusGix, Josh Gachnang, Adam Spiers and Michael J FeherThis 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 )
Reacted by Tom Spalding and Navin ChikkodiReacted by TeoAvignonReacted by TeoAvignonHi. Is there any update on this feature? It's super helpful when an external dependency has an error
Reacted by Alexis Delrieu, Tom Spalding, Navin Chikkodi, Mark Wylde and Akim DemailleMarch 12... we're suffering from this error too.
Reacted by Tom SpaldingI'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.
Reacted by Tom Spalding and Akim DemailleSurprised 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.
Reacted by Tom Spalding, AⱯ, cimak, Sofía Aritz, Wynn Wilkes, tcardlab, Zachary Keeton, Bryan Hoang, Adam Spiers, Akim Demaille and 2 moreRyan Cavanaugh (@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/Ywould be helpful.Reacted by knackstedt, Zachary Keeton, Gwenaël Hagenmuller and Akim DemailleIn my case I'd like to suppress TS2425 until this feature request is implemented: #48125
My project relies a lot on methods defined in mapped types. It's been agreed by the TS core team that disabling TS2425 for mapped types would be a solution, but after 3+ years that's not been implemented yet.
Next best thing is to disable TS2425 altogether (I don't care about that error anyways). But that's not possible either: so frustrating!
On an unrelated note: how does the implementation of these features work?
It seems relatively easy to implement a simple filter/blacklist for error codes, doesn't it?
How come has this issue (with more than a hundred votes) stayed open for almost 7 years? Nobody bothered to try and implement it, or is the core TS team against it for some reason?
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:
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.