Skip to content

Suggestion: option to have --noImplicitAny errors as warnings #13991

Closed
@jeffreymorlan

Description

@jeffreymorlan

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 string

This 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    DuplicateAn existing issue was already created

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions