-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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
Suppress no implicit any errors #1418
Conversation
…e of thier type e.g. File, Version, etc.., that was changed in the defintion to paramName, without changing the use site, changing it back to paramType.
Why does |
Looking at a build file, with Allowing only specific set of checks to emit, allows us to optimize the process by not querying for the errors if the user is not interested in them, instead of filtering a list after the fact. It also limits the usage matrix by designating a specific set of errors to suppress. In general error codes are just hard to remember, hard to maintain, and really no one wants to do unless they have to. At the essence of this issue, what users want is just disabling a specific check. a human readable name seems much suited to this end. Even in the original issue, @johnnyreilly asks for explicit names. |
I don't really buy all of these arguments. I would prefer if users still had the ability to provide error codes in addition to blessed names (which is ultimately what was requested in those threads) but if we want to consider doing that later if/when it's asked for then we can go that route. I don't think we need to throw out the generalized form (error codes) in order to provide human readable ones. I totally get that users don't want to deal with error codes unless they have to, but this blocks the 'unless they have to' case. By only supporting blessed names we're feeling like we're only adding 1 new compiler flag but it's essentially the same as adding N new ones where N is the number of blessed names. |
That is pretty much the intent. in the future if we need to suppress another error X, instead of adding a new --suppressX, we will use --suppress X. the benifit here is you do not have --suppresX --suppressY --suppressZ, instead --suppress X,Y,Z, |
@@ -1643,6 +1643,10 @@ | |||
"category": "Error", | |||
"code": 6054 | |||
}, | |||
"Suppress noImplicitAny errors for indexing into objects lacking index signatures.": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would might be better as "Suppress noImplicitAny errors for indexing objects lacking index signatures."
LGTM 👍 |
Conflicts: src/compiler/parser.ts src/harness/harness.ts
Suppress no implicit any errors
--suppress
switch--suppress implictAnyIndex
(noImplicitAny regression in 1.3 #1232, and Adding indexer to global Object makes other interfaces incompatible with Object #835)