TSServer: Refactor trigger reason

[mjbvz]

Follow up on #34930

Problem

VS Code lets user create keybindings for specific refactorings like extract constant. At present, TS Server does not know if refactorings are requested explicitly by the user using a keyboard shortcut or if they are requested automatically when the user simply makes a selection in the current document.

This distinction is important for a few reasons brought up in #34930:

• There are cases where we do not want the code action lightbulb to show up in VS Code but refactorings still should be availible if the user requests them
• The TypeScript server could be less strict about the selection for manually requested refactorings. For example, if I request to extract constant with no selection, TS Server could assume that I want to extract the nearest expression.

Protocol Proposal

In the getApplicableRefactors request, add a new triggerReason field:

interface GetApplicableRefactorsRequestArgs extends FileLocationOrRangeRequestArgs {
    triggerReason?: RefactorTriggerReason;
}

The trigger reason would capture why the refactoring was requested:

type RefactorTriggerReason = RefactorInvokedReason;

interface RefactorInvokedReason {
    kind: 'invoked';
}

At the moment, I think we only need a single trigger reason: invoked. I have based this design around the existing server API for parameter hints.

How TS Server could use triggerReason

As a first step, when refactorings are explicitly invoked by the user, if the current selection is not extractable, we should automatically expand the selection for extract constant and extract function to nearest extractable expression.

Possible extension: hierarchal refactorings

VS Code uses a hierarchal system to assign the class of code actions / refactorings. For example, extract constant has a CodeActionKind of refactor.extract.constant. Users can setup keybindings for refactor.extract (show all extract refactorings) or for refactor.extract.constant (show only the extract constant refactorings).

We should consider putting some form of hierarchical refactorings into the TS Server api as well. A few reasons this may be helpful:

• If TS Server knows the type of refactorings being requested, it can only compute that subset of refactorings
• In the future, we can specialize behavior for individual refactoring requests even more. For example, if a user explicitly requests extract constant refactorings for TS Server, we could show more than one expression around the current selection that can be extracted.

To support this in the server api, we would need to add a new another field on RefactorInvokedReason:

interface RefactorInvokedReason {
    kind: 'invoked';
    refactorType?: RequestedRefactoringType;
}

VS Code uses dotted string to represent a hierarchy of refactoring types (e.g. "refactor.extract.constant"). TS could also use this scheme. Or we could hardcode the hierarchy:

enum RequestedRefactoringType {
    Refactor,
    Refactor_Extract,
    Refactor_Extract_Constant,
    Refactor_Extract_Function,
    ...
}

[PranavSenthilnathan]

I think the hierarchal refactorings for tsserver is something we should add for the reasons mentioned here. @minestarks

[jessetrinity]

Can we close this since we added the refactor trigger reason, or does this item track the hierarchical refactoring as well?

[mjbvz]

From discussions, the TS team did seem interested in the hierarchical part of this proposal, so let's make sure we still track that, either with this issue or by opening a new one