Language-server-protocol: Support onWillRenameFiles to allow automatic updates to imports

[DanTup]

Similar to #873, but for will instead of did. This is the equiv of onWillRenameFiles: Event<FileWillRenameEvent> in VS Code.

Some language servers (including Dart) need to build the edits for updating import statements before the files are moved, so only telling the server after the event would not be enough.

[dbaeumer]

Anyone will to work on a PR on this?

[ericdallo]

That is a feature that we really miss on lsp-dart, it would be a great addition to the spec.

[DanTup]

@dbaeumer would something like this work? In VS Code the event has a waitUntil method which I don't think LSP can represent, so the options are probably limiting this to returning a workspace edit, or allowing the server to do its own work (eg. sending workspace/applyEdits) and the client waiting on a response before performing the renames.

WillRenameFiles Request

The workspace/willRenameFiles request is sent from the client to the server to inform the server about file/folder renames that are about to occur. The client will not perform the rename until the server has responded to this request and the client has processed any server-to-client requests sent prior to the response.

This request supports both files and folders therefore it is the servers responsibility to determine if any work needs to be done for a given rename (for example, whether a folder being renamed contains any files of interest).

A possible flow for this request would be:

• User invokes a file/folder rename action in the client
• Client sends a workspace/willRenameFiles request to the server but does not rename any files
• Server computes edits to update references to the moved files
• Server sends edits to the client using workspace/applyEdit
• Server waits for client to acknowledge the edits were applied
• Server responses to the workspace/willRenameFiles request
• Upon receiving the response, the client renames the folder/files

Client Capability:

• property (optional): workspace.willRenameFiles
• property type: boolean

The capability indicates that the client can send workspace/willRenameFiles requests.

Server Capability:

• property (optional): workspace.willRenameFiles
• property type: boolean

The capability indicates that the server can handle workspace/willRenameFiles requests.

Request:

• method: workspace/willRenameFiles
• params: WillRenameFilesParams defined as follows:

export interface WillRenameFilesParams {
    event: FileWillRenameEvent;
}

export interface FileWillRenameEvent {
    // An array of all files/folders being renamed in this operation. When a folder is renamed, only
    // the folder will be included, and not its children.
    files: FileRename[];
}

export interface FileRename {
    // A file:// URI for the original location of the file/folder being renamed.
    oldUri: string;
    // A file:// URI for the new location of the file/folder being renamed.
    newUri: string;
}

Response:

• result: null?
• error: code and message in case an exception occurs during the willRenameFiles event (this may include errors from the client when the server calls applyEdit)

TODOs:

• Should the response be text edits, or should the server send applyEdit commands?
• Dynamic registration?
• Should capabilities be objects instead of bools, so they can be extended in future?

[dbaeumer]

@DanTup thanks a lot for starting working on this. Highly appreciated.

I think we should take the same approach as with the willSave and offer a notification for the event and a request for the wait (see https://microsoft.github.io/language-server-protocol/specifications/specification-3-16/#textDocument_willSave and https://microsoft.github.io/language-server-protocol/specifications/specification-3-16/#textDocument_willSaveWaitUntil).

If we work on this I think we should cover all three cases of create, rename and delete (is more or less copy paste). PR as always welcome.

[DanTup]

Oh, my bad - I didn't realise there were already some "waitUntil" requests I should've been consistent with. I'll update this to match (maybe next week, out of office atm). Thanks!

[DanTup]

I've opened a PR at https://github.com/microsoft/language-server-protocol/pull/1074 for some initial feedback. Thanks!

[dbaeumer]

@DanTup my current plan is to release 3.16 as soon as the next VS Code stable build is out (mid December). Do you think you will be done with the evening until then?

[DanTup]

will be done with the evening until then?

I'm not sure I understand the question (evening?) but I'd really like to get this into 3.16 if possible. I pushed some changes to the PR at https://github.com/microsoft/vscode-languageserver-node/pull/687 so looking for feedback. I think implementing the "other 5" notifications/requests should be fairly easy once we're happy with the first.

[DanTup]

(As for the spec PR https://github.com/microsoft/language-server-protocol/pull/1074, I think I've addressed the comments and that's complete and just waiting for the implementation?)

[dbaeumer]

evening -> eventing :-)

[DanTup]

This was fixed by https://github.com/microsoft/language-server-protocol/pull/1074.