Proposal: preflight Unity .meta moves together with Explorer rename operations

[dmtiir]

Hello,

First, thank you for building Unity Plus. I have been looking for a way to improve the Unity workflow in VS Code while keeping the Microsoft C#, C# Dev Kit, and official Unity extensions.

I reviewed the current source and was pleasantly surprised by how much is already implemented. In particular, the use of the Microsoft rename provider, the combined type/script/meta preview, the Unity GUID index, and the YAML reference features look very useful.

While reviewing the direct Explorer rename path, I noticed that asset moves are currently observed through workspace.onDidRenameFiles, after which moveAssetMetaFilesForDirectRename applies a second WorkspaceEdit for the matching .meta files.

This appears to work for the normal case, but I wonder whether it could leave a partially completed Unity asset operation when, for example:

the destination .meta already exists;
the source .meta is missing;
applying the second workspace edit fails;
one item in a batch rename has a conflict while the other items do not.

buildAssetMetaRenameOperations currently skips conflicting items and continues building operations for the rest of the batch. That seems practical, but for Unity assets it may be safer to validate the complete operation before changing anything.

Would you be open to considering a preflight-based approach, possibly using workspace.onWillRenameFiles with event.waitUntil(WorkspaceEdit), or another design that you think fits the extension better?

The behavior I would find valuable is:

treat an existing asset and its .meta as one inseparable pair during rename or move;
validate the whole batch before applying any companion .meta operations;
report a clear conflict when the destination .meta already exists;
avoid generating a new .meta during rename or move;
keep creation of genuinely new scripts as a separate code path;
support files, folders, and batch moves consistently.

I may be overlooking limitations of the VS Code file-operation API or interactions with other extensions, so I am presenting this as a design question rather than assuming a particular implementation is required.

I can help with testing on macOS Apple Silicon. I can prepare a small Unity fixture and verify:

GUID preservation before and after rename or move;
references from scenes and prefabs;
single-file and batch operations;
folder moves;
destination .meta conflicts;
missing source .meta;
case-only renames on macOS;
interaction with Microsoft C#, C# Dev Kit, and Unity for VS Code.

I would also be happy to help add tests or prepare a small pull request after agreeing on the desired behavior.

Thanks again for working on this project.

[Caisusandy]

Thank you for the thoughtful write-up and for reviewing the existing implementation so carefully.

You're right: I did not fully consider the various partially completed states in the direct Explorer rename/move path. In particular, treating the asset and its .meta as a single operation, validating the whole batch up front, and handling destination conflicts clearly would make this much safer.

If you would like to contribute a small PR, that would be very welcome. Otherwise, I will revisit and fix this when I have time. Your proposed test matrix would also be very helpful for validating the final behavior.

Thanks again for raising this and for offering to help test on macOS.