feat: support resource operations

[cdaguerre]

This is my first experience with typescript, feedback much appreciated ;)

[UziTech]

Can you give some explanation of why this is needed? Examples of what this enables that doesn't currently work?

[cdaguerre]

@UziTech Sure!

This enables resource operations (basically file and directory operations) as part of workspaceEdits, which is currently not implemented at all.
I came across this while working on the rename functionality for the ide-intelephense package. If this PR makes it, i'll open another one to improve the rename functionality aswell (which to my understanding doesn't work at all right now).

From https://microsoft.github.io/language-server-protocol/specification#workspaceEdit:

Since version 3.13.0 a workspace edit can contain resource operations (create, delete or rename files and folders) as well. If resource operations are present clients need to execute the operations in the order in which they are provided. So a workspace edit for example can consist of the following two changes: (1) create file a.txt and (2) a text document edit which insert text into file a.txt.
And:

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

	/**
	 * Depending on the client capability
	 * `workspace.workspaceEdit.resourceOperations` document changes are either
	 * an array of `TextDocumentEdit`s to express changes to n different text
	 * documents where each text document edit addresses a specific version of
	 * a text document. Or it can contain above `TextDocumentEdit`s mixed with
	 * create, rename and delete file / folder operations.
	 *
	 * Whether a client supports versioned document edits is expressed via
	 * `workspace.workspaceEdit.documentChanges` client capability.
	 *
	 * If a client neither supports `documentChanges` nor
	 * `workspace.workspaceEdit.resourceOperations` then only plain `TextEdit`s
	 * using the `changes` property are supported.
	 */
	documentChanges?: (
		TextDocumentEdit[] |
		(TextDocumentEdit | CreateFile | RenameFile | DeleteFile)[]
	);

	/**
	 * A map of change annotations that can be referenced in
	 * `AnnotatedTextEdit`s or create, rename and delete file / folder
	 * operations.
	 *
	 * Whether clients honor this property depends on the client capability
	 * `workspace.changeAnnotationSupport`.
	 *
	 * @since 3.16.0
	 */
	changeAnnotations?: {
		[id: string /* ChangeAnnotationIdentifier */]: ChangeAnnotation;
	};
}

[UziTech]

LGTM just needs tests

[UziTech]

@aminya looks like linting is failing because of an issue with pnpm. Could you look into that?

[aminya]

@aminya looks like linting is failing because of an issue with pnpm. Could you look into that?

Yes, I will fix that.
https://github.com/atom-community/atom-ide-hyperclick/issues/132#issuecomment-818310509

[cdaguerre]

@UziTech I implemented handling of resource operation options and added tests.
Rollbacks of applied resource operations in case of error are not handled for now but I think it should ok for a first iteration.

[UziTech]

Should the delete operation be idempotent and fail silently if the file has already been deleted?

[cdaguerre]

I'm not sure.
LSP's CreateFile actually has an ignoreIfNotExists param.
What I implemented is:

• If ignoreIfNotExists is undefined, assume false and throw error
• If ignoreIfNotExists is true, return in case the file (or directory) doesn't exist

All ResourceOperations of such kind of params, notably overwrite, ignoreIfExists and ignoreIfNotExists.
I don't think that LSP gives any guidance on what should be considered the default value for such params, so I just assumed undefined === false, but I agree it might make sense to adapt with more sensible defaults...
WDYT?

[UziTech]

@aminya what do you think? I am on the fence on this one. On the one hand it makes sense to have undefined == false. On the other hand I don't see any situation where someone would want an error when deleting a file if the file already doesn't exist.

[cdaguerre]

I actually agree that a delete operation should not throw an error if the file doesn't exist.
For all other params/operation the sensible default would be false like :

• A rename operation should not overwrite another file and fail by default if the target exists (defaults: overwrite = false , ignoreIfExists = false
• A create operation should not overwrite another file and fail by default if the target exists (defaults: overwrite = false , ignoreIfExists = false
• A delete operation should not fail by default if the target doesn't exist (defaults: ignoreIfNotExists = true <== our case here

So in case of a delete operation:

const ignoreIfNotExists = edit.options?.ignoreIfNotExists || true

Agreed?

[cdaguerre]

@UziTech This is what I did: https://github.com/atom-community/atom-languageclient/pull/140/files#diff-9011b4bf132f9c2bff2dfede53c468cea4b1710ce6937a8948a733ca1f109c52R99
Basically the default behavior is: don't throw an error when deleting a file that doesn't exist, except if the server requested ignoreIfNotExists: false.

[aminya]

@aminya looks like linting is failing because of an issue with pnpm. Could you look into that?

#145 and #144 will fix the linting errors.

[cdaguerre]

I changed the code to use fs.stats and fixed linting/format errors.
Build is green! 🎉

[aminya]

Looks good to me. Thanks for your contribution!

[github-actions]

🎉 This PR is included in version 1.7.0 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)

Your semantic-release bot 📦🚀