I spent some time trying to get the asset pipeline to correctly delete files that had been removed (with a manifest), but it proved fiddly with too many edge cases, so I've separated out that work for now.

Compared to the simpler asset dir implementation, this is fiddlier (in particular hot patching deserves a close look), but feels clean and correct in use.

I was looking at Vite for inspiration and they have a public dir where the dir gets copied directly into the output public dir.

https://vite.dev/guide/assets.html#the-public-directory

I think we can support something like this instead of an "assets" directory. The old assets directory concept conflicts with asset!() calls since assets get duplicated between the two and its unclear when assets need to be hashed/optimized. It also had issues with desktop/mobile since you might not want to ship all the assets from that folder along with each platform, so auto-including it would be suboptimal. The public dir would only apply to web apps here, making it a bit clearer / more narrow.

It seems you have this mostly implemented here - maybe it's worth reframing the PR to match the vite public dir?

That way the final structure of the bundle looks like:

server.exe
public/
   /_wasm/
   /assets/
   index.html
   index.js
   /* rest of merged public folder */

When we merge the public folders together, we could allow files to end up anywhere in the output tree (even in the _wasm or asset folders), which should solve your original issue.

If you read into the vite docs a bit more, they have an /_immutable folder for infinitely hashed assets, and all other assets end up in /assets (both in the final public folder) - could be worth just stealing that entirely

Ah yes, I had implemented a simpler static dir approach AS WELL in a parallel branch (as I'd mentioned in #4778), which felt smooth and behaved well (and deleted files properly). I hadn't opened a PR for it because it looked like there was a move away from it, but I opened it in #4783 now.