fileops.md

File Level Operations

A workspace edit represents changes to many resources managed in the workspace. The edit should either provide changes or documentChanges. If the client can handle versioned document edits and if documentChanges are present, the latter are preferred over changes.

A workspace edit can optionally provide resource changes. If present resource changes are applies after the changes/documentChanges has been applied.

interface  WorkspaceEdit{
  TextEdit[] changes 
  TextDocumentEdit[] documentChanges 
  ResourceChange[] resourceChanges
}

ResourceChange

Changes to a folder or document on the workspace.

interface ResourceChange{

  /**
  * The resource change operation type
  */
  ResourceChangeType changeType
  
  /**
  * The resource. 
  * 
  * If change type is CREATE a new file is created on the uri with the given content.
  * The operation is ignored if uri is pointing to a folder. 
  * This will overwrite any existing files on this uri.
  * 
  * If change type is DELETE the resource is deleted if it exists. If the 
  * uri is a folder this operation deletes all its children too.
  * 
  * If change type is MOVE this uri is considered the source resource for the 
  * move and must point to an existing resource
  */ 
  Uri path
  
  /**
  * The new uri for the resource pointed by path.  
  * Used only if change type is MOVE. Must be compatible with the path 
  * uri ie. must be a file uri if path is a file uri.
  * 
  */
  Uri newPath
  
  /**
  * Required only if change type is CREATE
  */
  string content
}

enum ResourceChangeType{
  CREATE
  DELETE
  MOVE
}

If present resource changes are applies

If present, resource changes are applied

A couple of things:

1. changes, documentChanges and resourceChanges should be optional ("?")
2. Uri path is a contradiction in itself. Shoudl be "uri". Same for "newPath". Is Uri a type in typescript?
3. "newPath", "content" should be optional.

Your proposal is a straightforward extension of the current WorkspaceEdit structure. I find the WorkspaceEdit structure as it is now a bit strange: it should really be:

changes: { [uri: string]: TextEdit[]; } | TextDocumentEdit[];

instead of two optional fields. However, your extension would still apply the same.
From the proposal, it's clear that folders can be targets of resource changes. In that case, we can construct changes that can be order-dependent (move file that has been deleted before in the script). We need to either state that the changes are executed in-order or we need to disallow or disambiguate certain change patterns.
You use "file uri" in the description. Does that mean a uri starting with "file://" or one that designates a file as opposed to a folder?

In one of the issues on this topic there was a suggestion that it would be enough to provide a "delete" flag on changes. Create would be an insert of [0,0:<file contents], move would be delete + insert. Have you thought along those lines and if yes, what are you reasons to go with the current idea?

@tsmaeder Yes I did think about not having an explicit move. I decided to do an explicit one because it is easier to implement on the client especially for folders. Also I want to enhance FileChangeTypes in the future to make it easier to detect moves and renames, wanted to have some compatibility.