This is ready for review now.

Also, I wonder if bringing in files from git repositories could be expressed as a "read-only mount" 🤔 This would neatly interop with the CLI version.

I know it's a large one and might be difficult to review. There's a few things I could extract, but unfortunately most of it is an atomic change. If nothing stands out, we could try deploying that on Monday with full readiness to rollback.

I pushed 4d1a539 which passes around OPFS paths rather than FileSystemDirectoryHandles which due to the Safari structuredClone() not supporting that.

It looks like this may fix #1239 because Safari is loading Playground with browser storage locally after this change.

There are some merge conflicts with trunk, so I'll look at those next.

I missed some thing in the original switch from passing OPFS handles to passing OPFS paths, and those should be fixed now.

I am currently seeing a bug with creating a new site on device storage:

index.tsx:139 Uncaught (in promise) DOMException: Unable to resolve path of OPFS directory handle.

Discovered while testing for this review comment:
https://github.com/WordPress/wordpress-playground/pull/1669/files#r1705279446

Looking into it.

It looks like I was mistaken about the "fix" for this PR because we aren't just passing around opfs paths. FileSystemDirectoryHandles are also used for local FS access, so we cannot just pass paths around and assume they are for OPFS.

Since FileSystemDirectoryHandle instances cannot be transferred via postMessage() in Safari, we need a different solution.

Continuing to look into this.

One thing to remember is that Safari doesn't support direct local FS access via showDirectoryPicker(). So we could consider passing FileSystemDirectoryHandles for the local FS case because local FS access doesn't work in Safari anyway.

I worked on adjusting this to use the following types:

export type MountDevice =
	| {
		type: 'opfs';
		path: string;
	  }
	| {
		type: 'local-fs';
		// Since we have to prompt the user to get the FS handle,
		// we cannot simply save a path and recreate the handle
		// like we can do for OPFS. So we have to pass the handle between threads.
		handle: FileSystemDirectoryHandle;
	  };

export interface MountDescriptor {
	mountpoint: string;
	device: MountDevice;
}

Safari doesn't support structuredClone() for FileSystemHandle or the platform features we use to interact with the local device filesystem. Since we don't support local-fs sites on Safari, we shouldn't run into structuredClone() errors due to the FileSystemDirectoryHandles.

It also seemed good to rework how we were passing mount options, but there were issues due to progress callbacks making it into postMessage payloads and causing DataCloneErrors. So I'm working on backing those changes out so this can work.

This PR should be working again in Safari and for local device sites.

@adamziel, please let me know if you have any thoughts on this. I'm planning to give this another read tomorrow or Monday and then merge if all is well.

I reviewed this again and found and fixed an issue with site reset.

Fantastic work here @brandonpayton 🎉