Extend Diff type

[anna239]

Current Diff data type doesn't support following scenarios:

• file deletion
• file move
• non-text files

Suggestion:

type Diff = {
  type: "diff";
  oldPath?: string | null;
  path: string;
  oldContent?: FileContent | null;
  newContent?: FileContent | null;

  /** @deprecated Use `oldContent` instead. Only valid for text content. */
  oldText?: string;

  /** @deprecated Use `newContent` instead. Only valid for text content. */
  newText?: string;
};

type FileContent = TextFileContent | BinaryFileContent;

for removed file newContent is null
for moved file oldPath is present
further types of file content can be supported in the future — like resource links and so on

[benbrandt]

This is great. So to sketch out what all of the scenarios would be, we'd have:

(not sure what the text vs binary types look like)

File added:

{
  type: "diff",
  path: "/path/to/a",
  newContent: { text: "foo" }
}

File deleted:

{
  type: "diff",
  path: "/path/to/a",
  oldContent: { text: "foo" },
  newContent: null // or { text: "" }?
}

File move:

{
  type: "diff", 
  oldPath: "/path/to/a",
  path: "/path/to/b"
}

File edit:

{
  type: "diff", 
  path: "/path/to/b",
  oldContent: { text: "foo" },
  newContent: { text: "bar" },
}

File edit + move:

{
  type: "diff", 
  oldPath: "/path/to/a",
  path: "/path/to/b",
  oldContent: { text: "foo" },
  newContent: { text: "bar" },
}

[anna239]

I like null more for the newContent of deleted file.
Regarding the binary type. In Junie we use ByteArray for that, but I imagine that can be not very conventional in some languages. Maybe we can have base64 encoded content there?

[benbrandt]

Yes base64 seems like a good strategy, seems the common pattern for this sort of thing

[benbrandt]

On another note: I've received some feedback from that generating the diff can be difficult.
We could allow for a unified diff of some kind in this case... But I'm not sure. Like the agent would have to generate at it, and then the client could render it as is, maybe with some color, or else they have to parse it.

I think it is also fine to say we leave it up to the client so they can choose. there are plenty of diff libraries for various languages and it provides them with control of how to render it. But I'm just curious if you have any thoughts from the JetBrains side of things on if there is an improvement here from the client side for actually representing the diff.

[anna239]

I would say client can just pick a library for diff presentation, as you said, there is plenty of them for different languages. And also I think the choice depends on how you're representing the diff — browser, cli, ...