codeFixes for things that aren't diagnostics

TypeScript Version: 2.7.0-dev.20171020

Code

function f(x) {}

It would be nice to have a codeFix to fix implicit-any instead of a refactoring. I believe a refactoring requires you to highlight the thing in question, which isn't easily discoverable.
Currently codeFixes work by iterating over errors; but in this case we would want to produce one even in an error-less build.
This would also help us avoid having to create codeFix / refactor pairs for things such as installing types for implicit-any packages.
We could also generate "info" errors (ref: #14501) that don't surface normally and make codeFixes for those.

CC Matt Bierner (@mjbvz)

[DanielRosenwasser]

Andrew Casey (@amcasey) was talking about how this is enabled with "info" diagnostics in Roslyn

[amcasey]

I asked about this at today's design meeting and the consensus seemed to be that we should create a separate (linter-like) tool to detect such cases and then offer to fix them (i.e. that this doesn't belong in the compiler).

It wouldn't be easy to create a separate tool to detect implicit-any without duplicating code from the compiler -- unless you clone the project, change the compiler options, and type-check again, which is what tslint's no-unused-variable currently does. But that rule is slow and thus not enabled by default; supporting a lint rule for every compiler option like that would result in a lot of clones.

[amcasey]

I understood that we proposed to add new compiler APIs (e.g. getImplicitAnyDeclarations) on a case-by-case basis as we determined that doing the work in a separate tool was infeasible. I believe it was Mohamed Hegazy (@mhegazy) who brought it up.