i would call this Suggestion.

Removed

just name

getSuggestionDiagnostics

Removed

this is not going to scale as we add code fixes. we can not call every code fix on every node on the tree, we need a more efficient way.
We could make codeFix register a SyntaxKind it is interested in, this will save us the dispatch on every node at least.
Alternatively, we can have the code fix return a Boolean whether to keep walking or not, this way we avoid walking expressions that we do not care about.

Codefix feature removed

i think we need to optimize this function and getCodeFixDiagnostics.

i would say this should be limited to the declaration, not on every reference.

I would also say you do not need the checker here.

Ideally we want this to be syntactic in nature, passing in the program allows for getting the checker. this can be expensive if the codeFix author do not know what they are doing, consider not passing in the program, but just a sourceFile and options.

We also want to use the same mechanism for refactorings. a refactoring should have isApplicable, and getCodeActions. I would recommend switching this into isApplicable, and an optional diagnostic message.

consider unifying this with the codeFix isApplicable. ideally we can have one implementation that serves as both a refactor and a codefix + suggestion provider.

should be a diagnostics message for localizability.

It is kind of random that on any expression i can refactor the containing function to include async. i would say this has to be on function/method declaration at least.

just isApplicable, the positionOrRange is implied from the arguments.

This should be in diagnostics

Removed this refactor

should be in diagnostics to ensure localizatability.

kinda silly comment, but can we have (startPosition, endPoisition) instead of positionOrRange? every refactor author has to write the same check typeof positionOrRange === "number"?...

Actually why not just put these on the RefactorContext? we put the errorCode on the codeFix context.

Makes sense

i would use isNameOfFunctionDeclaration or something similar.

i would check if token is one of identifier, function keyword, public, private, protected, or static , and their parent is a FunctionDeclatation or MethodDeclaration.

File removed

Is this intended for a .ts or a .js file?

I think it is a .js file, since the binding for the special properties do not work in .ts files any way.

If my understanding is correct, then for static members we can not just add declarations for them, this will result in invalid .js class.

this also applies to the property declarations and assignments..

If we want this to work in a .ts file, then we need to do something with the inference to make it work first.

I would also recommend adding a check at the top of isApplicable to return if !inJavaScriptFile(node)

also for member initialization, I wounder if we can even do these correctellly...

var c = function() { this.list.push(1); }
c.prototype.list = [];

is not the same as:

class c {
    constructor() { this.list.push(1); }
    list = [];

let a side that it is not valid JS strictly speaking.

Fixed these up. Non-func-expr things remain as assignments following the class body

consider in-lining the const in the call and using the contextual type instead.

I would check the cancellation token here.

what is the value of the split here?

what about cancellation token?

consider exposing CodeFixContext minus errorCode.

This should be marked as /* @internal */

A comment here would be good.

why is this optional?

why is this optional?