VS Code is investigating the concept of autofixable quick fixes. You can find the current proposal here

Motivating use case

You open the following TS file:

interface IFoo {
    bar(): void;
}

class Foo implements IFoo { }

new foo()

This file has two errors: incorrect interface implementation on class Foo and a spelling error in new foo()

You hit F8 to start navigating through errors. While navigating, you can hit a single keyboard shortcut to auto implement the interface or to correct foo -> Foo

Current VS Code proposal

To implement auto fixes, VS Code currently proposes that some quick fixes be marked with a canAutoApply flag. This flag would indicate that:

• The quick fix will fix the underlying problem (and not suppress it or hide it)
• The quick fix can be fairly safely automatically applied without user input
• The provider of the quick fix is relatively confident that the quick fix could be correct (100% confidence is not required since the auto fix is being triggered by a user action). More importantly, the quick fix should be easy to undo if it is incorrect

When the user hits auto fix in VS Code, if only a single canAutoApply quick fix is returned for a diagnostic, VS Code would automatically apply it. If multiple canAutoApply fixes are returned, we would show a list of these for the user to select from. The existing, more complete list of quick fixes and code actions could still be accessed using the lightbulb menu

Proposal for TS

The UX experience of being able to auto fix errors with a single keyboard shortcut is very nice and I think we can make reasonable fix assumptions about a fair number of real world errors. The work that would be required on the TS side to support the proposed auto fix feature in VS Code:

• Add an optional canAutoApply property on the TS CodeFix objects
• Add some logic to decide when a fix can be marked as canAutoApply. //@ts-ignore fixes for example should never be marked as canAutoApply but spelling errors, add missing this, and perhaps even add missing import could be.

The initial implementation would only need to support canAutoApply for a small set of diagnostics, which could be expanded in future releases.

/cc @DanielRosenwasser, @minestarks, @amcasey