It would certainly be interesting if the editor was just one crate in your game's workspace. Initially with default plugins, but then you could expand it with plugins depending on your use cases.
Then, cargo could be our plugin manager for the editor :)

Finally, remember that this feature doesn't make your app multi-threaded by itself!
It just simplifies the process of building and running already multi-threaded apps.

Try out bevy_seedling with firewheel_web_audio to get started with multi-threading, which uses it for audio. No more stutters!

This is all not very accessible, so the CLI prototype automates it for you!
It also adds the rustflags gracefully without overwriting existing rustflags in the project (which would happen if you specified them manually).

Hopefully this will accelerate development of Wasm multi-threading in Bevy.

First, you need to manually enable the Wasm multi-threading features, then also rebuild std with those features (which requires nightly).
But when you run the app, it still wouldn't work!
Turns out, security is important. So browsers require you to enable cross-origin isolation headers.

Currently, Bevy runs everything on a single thread when you are targeting the web.
This leaves a lot of performance on the table and can lead to issues like stuttering audio.
Some third-party plugins are adding support for running some parts in different threads, but it makes them quite hard to run!

2. github.com/TheBevyFlock...

This allows you to specify additional response headers for the local web server used for `bevy run web`.

It was already possible to pass them directly in the command via `--headers`, but with this PR you can also persist them in the `Cargo.toml` via our config system.

We initially only accounted for the directory to not be a Cargo workspace, but there can be multiple other failure cases that turn out to come up more in practice.

We now ensure that the user can see the original error message by `cargo metadata` to diagnose the issue.