WorkspaceEdit is incompatible with the protocol

[KalitaAlexey]

https://github.com/Microsoft/vscode-languageserver-node/blob/master/types/src/main.ts#L366

export interface WorkspaceEdit {
	changes: TextDocumentEdit[];
}

In the protocol it described as follows:

interface WorkspaceEdit {
    /**
     * Holds changes to existing resources.
     */
    changes: { [uri: DocumentUri]: TextEdit[]; };
}

Also asWorkspaceEdit is wrong.

This is cause of the problem in my extension.

It worked on "vscode-languageclient": "^2.6.3", but it doesn't on "vscode-languageclient": "3.0.4".

[gorkem]

@dbaeumer 73d3500 seems to have broken the asWorkspaceEdit. This is now a blocker for redhat-developer/vscode-java#99 since we can not move to the 3.x version of the library.

[dbaeumer]

@gorkem I will have a look. I know that we discussed this but I need to refresh my memory.

[dbaeumer]

Reading through the code I remember why we changed this for the 3.0 version of the protocol. The reason was that the old WorkspaceEdit was a map from URI to edit. The problem was that this didn't allow to specify on which version of a document an edit is applicable. This is why we changed this from a map to an array where the TextDocumentEdit contains a textDocument property pointing to a VersionedTextDocumentIdentifier.

I know this is breaking but to support proper version checking when applying text edits this was the best way to go forward. Now users of the protocol have to think about this.

So bottom line is that the spec is incorrect. I will fix this. Would you be able to adopt this?

[gorkem]

I am concerned that this will break all the existing implementations, not all clients are able to move as quick. I think we need a migration path on this. Perhaps we can leave the changes as a deprecated field and use something like edits for the TextDocumentEdit.

I think we should consider microsoft/language-server-protocol#41 before making changes to WorkspaceEditon the protocol.

The chaps on LSP4J @svenefftinge or @akosyakov can tell how quickly they can respond to such changes. It is pretty quick for jdt.ls once LSP4J has a build with adopting changes

[dbaeumer]

I updated the documentation / spec of the protocol.

[dbaeumer]

The old clients is a fair argument. Addressing this should be done like all the new features in 3.0.x. We should have a client capability property specifying which type of work space edit the client expects together. If the new format is not supported by the client then we should return the old structure. I missed this for this change but did it for all new features for 3.0.x. Don't know why I forgot it here. Will look into this this week.

[dbaeumer]

What I will do is the following. I will declare WorkspaceEdit as follows:

/**
 * A workspace edit represents changes to many resources managed in the workspace. The edit
 * should either provide `changes` or `documentChanges`. If documentChanges are present
 * they are preferred over `changes` if the client can handle versioned document edits.
 */
export interface WorkspaceEdit {
	/**
	 * Holds changes to existing resources.
	 */
	changes?: { [uri: string]: TextEdit[]; };

	/**
	 * An array of `TextDocumentEdit`s to express changes to specific a specific
	 * version of a text document. Whether a client supports versioned document
	 * edits is expressed via `WorkspaceClientCapabilites.versionedWorkspaceEdit`.
	 */
	documentChanges?: TextDocumentEdit[];
}

and add a ClientCapability:

	versionedWorkspaceEdit?: boolean;

If set the by the client the server is allowed to send TextDocumentEdit arrays in the property documentChanges.

[dbaeumer]

The correct client capability will look like:

export interface WorkspaceClientCapabilites {
        ...
	/**
	 * Capabilities specific to `WorkspaceEdit`s
	 */
	workspaceEdit?: {
		/**
		 * The client supports versioned document changes in `WorkspaceEdit`s
		 */
		documentChanges?: boolean;
	};
        ...
}

[dbaeumer]

A fix is available on release/3.2.0-alpha.1. Need to review tomorrow and then deliver a next release.

[akosyakov]

@gorkem lsp4j is updated according to changes in the protocol: eclipse-lsp4j/lsp4j@46b8d7a

[dbaeumer]

I pushed a 3.2.0-alpha.x version to npm under the next tag in case you want to give it a try.