-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
noImplicitAny regression in 1.3 #1232
Comments
This was an (unannounced) breaking change. See #835. |
Incidentally, this was a massive breaking change for us too - especially within the test harness. It seems a bit ironic in the light of new features being turned down, because they _may_ (i.e. potentially) introduce a breaking change (e.g. #16). We had no problem going through the code base and fixing this particular breaking change (and actually ended up fixing a few holes as a result) thanks to the refactoring magic now possible because of TypeScript. |
What pattern are you using now? Are there any plans in the future to establish a pattern on how to do this as this is a common scenario? |
I feel like we need some kind of solution here, since we already have many thousands of lines of code that rely on it without an easy way to refactor. Also there are plenty of times that it is very ugly to do any casts. Which do you think is more readable?
vs
To me the first is much cleaner, especially when you're chaining or passing properties values as arguments to other functions. |
The point is when we decide to compile with Also note that it is only an error if the property var obj = {
bar: 10
};
obj['foo'] = 10; // Error: Index signature of object type implicitly has an 'any' type
obj['bar'] = 10; // Okay Unfortunately, most often what happens is the following: var bar = 'bar';
obj[bar] = 10; // Error: Index signature of object type implicitly has an 'any' type There is no quick fix for this. The only solution is to go through the errors and ensure the index signature is modelled correctly: interface NumbersOnly {
[index: string]: number;
}
var obj: NumbersOnly = {
bar: 10
};
var bar = 'bar';
obj[bar] = 10; // Okay This is what we should expect to do, when deciding to go the Clearly the interface NumbersAndStrings {
[index: string]: number | string;
} |
I should also add that the situation with enums is more elaborate and rather unsatisfactory: interface EnumIndexer<TValue> {
[index: string]: TValue;
}
enum Foo {
one,
two
}
var one = 'one';
var num = (<EnumIndexer<Foo>><any>Foo)[one]; |
I agree with the above, but the interface extension on |
Just FYI other Definitely Typed definitions rely on this quite heavily as well. For an example check out angular.d.ts (https://github.com/borisyankov/DefinitelyTyped/blob/master/angularjs/angular.d.ts) interface IAttributes {
[name: string]: any; interface IFormController {
[name: string]: any; interface IModelValidators {
[index: string]: (...args: any[]) => boolean;
}
interface IAsyncModelValidators {
[index: string]: (...args: any[]) => ng.IPromise<boolean>;
} and a few more but you get the point. tagging @vvakame @Bartvds @johnnyreilly just as an FYI. |
There is some special treatment for index signatures on apparent types: they are not inherited. I believe this was due to a change in the spec: Old spec (3.8.1):
According to the last line, adding an index signature on I am not aware of the reason for this change. |
We've been talking about this a bunch the last couple days. Here's an explanation of how we got into this spot and how we're thinking about changing it: Brief History of Indexers on ObjectThis string indexer was once defined on The BreakUpon the introduction of Proposed SolutionIt seems clear at this point that What we are thinking at the moment is to leave the current behavior as is, but add a generalized way to suppress all errors with a particular error code. This lets people opt in and out of varying checks without creating an impossible to reason about matrix of compiler flags and difficult to manage implementation. Concretely, for those who want the behavior you get today with the
This will also scale nicely with any new stricter mode (ex #274) without requiring a new compiler flag per additional strictness check. Any objections or other feedback on the proposed solution (or alternative solutions) are appreciated. |
@danquirk, I like the proposed solution. A couple of points:
I do not have an objection to this, because I have always been an advocate of stricter type checking, and it's unlikely that we'd use the BTW, that's a very skilfully constructed climbdown for introducing a breaking change 😃 |
First of all, great news that you're thinking about splitting So yes! (Punches the air) I like the proposed solution's flexibility - that totally makes sense rather than having to continually add new compiler flags. I share @NoelAbrahams reservations about bug reporting. I don't suppose you'd consider having simple string aliases for the error codes? Given how many error codes there are maybe it would only make sense to provide aliases for the "popular" / often opted out of error codes.... So perhaps this might be possible? So for example:
Where Alternatively the user could just use this:
Which means exactly the same but is less human-readable. |
We don't get terribly many "I didn't get an error when I thought I should" bugs so I'm not too worried about that case. Optionally we could write on the commandline the number of suppressed errors as a reminder or something. My hope is that the median number of suppressed error codes would be 0 -- that should be what we aim for. One thing we discussed was to just remove the implicit Object indexer warning from If I could wave a wand and get some data, I'd like to see how many people have added the indexer to |
I've already mentioned Angular. And this issue was created by WinJS team. A few more samples : https://github.com/borisyankov/DefinitelyTyped/pull/1779/files && https://github.com/borisyankov/DefinitelyTyped/pull/2272/files#diff-d3e001dd03f4c618484e97ea6957518cR2 |
I did this in tsUnit - I thought you might have resolved this issue, though, because I no longer appeared to need that fix so removed it 5 days ago... |
👍 on this "One thing we discussed was to just remove the implicit Object indexer warning from noImplicitAny and add it back as one of the first errors in #274" If we don't want to support an easy way of fixing this, let's just pull out the check here and be more thorough when we have a stricter mode. |
This would be great :) |
The --suppressImplicitAnyIndexErrors flag should be in branch release-1.4 now. |
I've an Angular2 related Issue: myData is defined as:
It actually works properly but the TypeScript-Compiler outputs an error:
I've tried to suppress this error by switching off the following flags in the tsconfig.json (compilerOptions):
It did not work. Can someone help me further? Second question: Is it possible to suppress certain errors (e.g. TS7017) in tsconfig.json? If yes, how? I would like to achieve something like (e.g. in the
p.s. thank you very much! |
@webia1, this is a year old issue. it is not related to the question you posted. In the future we would appreciate it if you can start new tickets instead of commenting on closed issues. also SO or the ts gitter room would be better venues for such questions. this issue tracker is mainly for TS compiler and tools bugs. As for your question. The containing class (refereed to in this context using Setting see http://www.typescriptlang.org/docs/handbook/interfaces.html#indexable-types for more details. |
Thank you, that helps completely,.. |
Pre 1.3, with
--noImplicitAny
flag on, having the following:would enable this type of scenario:
However, now this results in an implicit-any error. The winjs/winjs team uses this pattern a lot to add and access members on various objects and this is blocking us from moving to 1.3.
The text was updated successfully, but these errors were encountered: