Description
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 constantwith 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 constantrefactorings 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,
...
}