Ignore Specific Error [AGAIN]

[Aurailus]

Yes, this is a duplicate of #11051, but that issue is closed and this NEEDS to be addressed.

People use Typescript for more than just Javascript compilation now. There are tons of transpilers that convert TS to all sorts of useful languages. Typescript must have a proper way to disable certain error codes project-wide.

My specific issue right now is that I'm using TypescriptToLua, a Typescript transpiler that produces lua code, and Typescript throws a fit whenever I try to use mathematical operators on classes. This would make sense if I was compiling to Javascript, but I'm not, but I'm forced to annotate every line with @ts-ignore (unrealistic) or suffer through constant reports of TS2362 and TS2363 in my console (infuriating).

There could easily be an ignoreErrors: number[] in the .tsconfig file that provides this functionality. The only thing stopping it from existing is stubborness. Well designed errors that never cause issues are a nice dream, but realistically there will always be use cases that are not met by the error handler, and the user should have the power to suppress invalid warnings.

A short example of my issue:

Typescript that will be converted using TypescriptToLua:

/** @customConstructor vector.new */
declare class Vector {
	constructor(x: number, y?: number, z?: number);
}

const v = new Vector(1, 2, 3);
const vSquared = v * v;

Generated (valid) lua code:

--[[ Generated with https://github.com/TypeScriptToLua/TypeScriptToLua ]]
v = vector.new(1, 2, 3)
vSquared = v * v

Obnoxious compiler output:

main.ts:9:18 - error TS2362: The left-hand side of an arithmetic operation must be of type 'any', 'number', 'bigint' or an enum type.

9 const vSquared = v * v;
                   ~

main.ts:9:22 - error TS2363: The right-hand side of an arithmetic operation must be of type 'any', 'number', 'bigint' or an enum type.

9 const vSquared = v * v;
                       ~

Thank you for your time, I hope that this issue can be seen as what is is, which is a frustrating lack of user control and agency.

[Aurailus]

Bumping this issue because I'm once again in a situation where I need to ignore TS2362 and TS2363 when type checking, as I'm using a Babel plugin to add support for Operator Overloading. Come on guys, it might be a pain to implement, but it would be a massive help for everyone who wants to do something even slightly unconventional with TypeScript, and it expands the use-case of TS a ton.

[Aurailus]

If I implement it, would the team be receptive to a push upstream?

[RyanCavanaugh]

The issue is not that none of us have the time to implement it. Our current position is that it is a bad idea and should not be in the product.

[Aurailus]

I'm not sure I see the logic in that, no matter how good the analysis of the compiler is there will still be edge cases where things are falsely flagged, or transpilers handle a new language feature that TypeScript isn't prepared for, or errors are flagged that just don't apply to someone's project, and it would be much more convenient and developer-friendly to just be able to disable the warning project-wide. I understand that this isn't an option that most people would benefit from, but I fail to see how it would negatively impact the project or its users to have an option for the few that have genuine edge cases and need an escape hatch. It really feels like a must-have given the nature of the Javascript/Typescript ecosystem, and the sheer diversity of language feature proposals, preprocessors, alternate syntaxes such as JSX, and other complexities that would be more of a pain to support explicitly than to simply allow the compiler to ignore. I urge the Typescript team to reconsider, or at least rediscuss this issue and see if there's a better solution than just strict denial.

[chkpnt]

💯! I'm working on a legacy JS project with tons of warnings that can't simply be fixed. I really like to have the compiler's hints, but it's a pity the important ones get lost in the shuffle. The world isn't black and white, I confirm the need for the ability to opt-out for specific checks. Either by a project wide setting as suggested by @Aurailus or on a file level with something like @ts-nocheck:#1,#2,... (I'd prefer the second option as it allows smaller refactorings when working on the mitigation of a specific issue).

[AncientSwordRage]

I'm using typescript checking of JS files so I can use typescript-style JSDoc types. I don't need a lot of the other rules checking though. Switching off those rules is really important to me

[dbalatero]

I figured out how to use the TypeScript AST to detect problem spots where ts-expect-error might be hiding other errors:

https://gist.github.com/dbalatero/82bb17596fe4e8b7d1c5d56d8f6018fb

If you want to try it on your codebase, you can try dropping it in and wrapping it in a little script like I show in the README.