-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Suggestion: option to have --noImplicitAny errors as warnings #13991
Description
When migrating a large JS project to TS, one may find it infeasible to make the whole thing --noImplicitAny compliant at first, but still want to minimize the use of implicit anys in new code. I made my editor plugin always enable noImplicitAny errors unless explicitly disabled, but show them as warnings unless explicitly enabled. This worked great for a long time.
But in TS 2.1, there's a problem with this: --noImplicitAny now affects type checking due to the new control flow analysis. It can now add errors seemingly unrelated to implicit-any in some places, and remove them in others:
var a;
a = 0;
a.foo; // ok without --noImplicitAny: a has type any
// error with --noImplicitAny: a has type number
function last<T>(arr: T[]) { return arr[arr.length - 1]; }
var b;
b = ["foo"];
last(b).charAt(0); // error without --noImplicitAny: last(b) is inferred as type {}
// ok with --noImplicitAny: last(b) is inferred as type stringThis is a problem for the noImplicitAny-as-warnings feature in my editor, because the actual errors won't match up with command-line tsc or with other editors. I'll probably relegate it behind a nonstandard tsconfig.json option, with the understanding that it does have this problem.
But it would be nice if it could be a standard option instead. Not on by default, but suppose that noImplicitAny could be any of false, true, "warn". When set to "warn", tsc would enable the control flow type analysis but not report implicit-any errors, and editors would enable the analysis and report them only as warnings.