Skip to content

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

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

Closed
jeffreymorlan opened this issue Feb 10, 2017 · 2 comments
Closed

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

jeffreymorlan opened this issue Feb 10, 2017 · 2 comments
Labels
Duplicate An existing issue was already created

Comments

@jeffreymorlan
Copy link
Contributor

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.

@DanielRosenwasser DanielRosenwasser added the Suggestion An idea for TypeScript label Feb 11, 2017
@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Feb 11, 2017

Related is #6802, which calls for configurable error messages.

@mhegazy
Copy link
Contributor

mhegazy commented Feb 22, 2017

seems to be covered by #13408 and #6802.

@mhegazy mhegazy added Duplicate An existing issue was already created and removed Suggestion An idea for TypeScript labels Feb 22, 2017
@mhegazy mhegazy closed this as completed Apr 21, 2017
@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Duplicate An existing issue was already created
Projects
None yet
Development

No branches or pull requests

3 participants