Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tsconfig - Ignore errors by ids #29950

Open
sancarn opened this issue Feb 18, 2019 · 11 comments
Open

tsconfig - Ignore errors by ids #29950

sancarn opened this issue Feb 18, 2019 · 11 comments

Comments

@sancarn
Copy link

@sancarn sancarn commented Feb 18, 2019

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

This comment has been minimized.

Copy link

@pablobirukov pablobirukov commented Feb 19, 2019

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

This comment has been minimized.

Copy link

@milesj milesj commented Feb 19, 2019

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

This comment has been minimized.

Copy link
Member

@RyanCavanaugh RyanCavanaugh commented Feb 19, 2019

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

This comment has been minimized.

Copy link

@milesj milesj commented Feb 19, 2019

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

This comment has been minimized.

Copy link
Author

@sancarn sancarn commented Feb 20, 2019

@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

This comment has been minimized.

Copy link
Member

@RyanCavanaugh RyanCavanaugh commented Feb 20, 2019

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

This comment has been minimized.

Copy link

@dcodeIO dcodeIO commented Apr 5, 2019

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

This comment has been minimized.

Copy link

@SSPJ SSPJ commented Jun 7, 2019

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

This comment has been minimized.

Copy link

@deenem deenem commented Jun 21, 2019

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 caleb15 mentioned this issue Aug 23, 2019
5 of 5 tasks complete
@caleb15

This comment has been minimized.

Copy link

@caleb15 caleb15 commented Aug 23, 2019

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

This comment has been minimized.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.