Taking this example for a spin

Assuming you have the shadow-cljs npm package installed:

1. From the shadow/ directory, run shadow-cljs release extension and wait for the build to complete.
2. Go to "chrome://extensions".
3. Toggle on 'Developer mode' in the top right of the page.
4. Click the 'Load unpacked' button and find ~/[...]/hacky-chromex-shadow-manifest-v2-to-v3-migration/shadow/resources/unpacked.

Changes made (and why)

1. Versions in deps.edn bumped to latest, and binaryage/chromex made a non-local dependency. (commit)
2. :manifest-version in shadow/resources/unpacked/manifest.edn bumped from 2 to 3. (commit)
3. Introduced a shadow-cljs build hook, to run at the very end of the build. This is responsible for all of the hacky patching required to get this thing working. (commit)
   1. Patched "background" key in manifest. (commit)
      • Under Manifest V3, the "background" key can only take a single "service_worker" where before it took an array of "scripts".
      • This is why we ignore all "scripts" but "out/background.js", here.
   2. Prepended copy of out/shared.js to out/background.js. (commit)
      • Even developing against release builds, shadow generates multiple "background" scripts: out/background.js, out/bg-shared.js, and out/shared.js. So whilst it's possible under Manifest V3 to declare the background "service_worker" an ES Module and statically import such additional code into out/background.js, out/shared.js currently doesn't export stuff in the necessary way.
   3. Patched "content_security_policy" key in manifest. (commit)
      • It has a different shape in Manifest V3.
   4. Removed 'unsafe-eval' from Content Security Policy. (commit)
      • Again, Manifest V3 doesn't allow it.
   5. Patched "actions". (commit)
      • It has a different shape in Manifest V3.
   6. Fixed permissions. (commit)
      • Host permissions are declared separately in Manifest V3.

Some questions!

1. Regarding (3)(ii) above, perhaps hot reloading of code during development could be recovered if there were a way to deal with the many background-relevant scripts that shadow-cljs watch extension generates in addition to out/background.js — as opposed to just out/shared.js for shadow-cljs release extension. So... aside from prepending every single one to out/background.js, what options are there?
   1. They could potentially be statically imported if shadow threw a few exports in during building, right?
   2. Something else?
2. With 'unsafe-eval gone in Manifest V3, even during dev, it's unclear how to get a REPL hooked up to the various runtimes comprising a running extension. (Related shadow-cljs issue/comment: thheller/shadow-cljs#902 (comment).) And even if it were possible, the short-lived nature of background service workers (replacing Manifest V2's background pages) would make REPL-driven dev against background-related cljs files annoying... probably. Are there any good solutions here, aside from maybe:
   1. Developing against Manifest V2 in a V3-compatible way, then building the extension as V3?
   2. Developing against a modified Chromium, enabling unsafe-eval?
3. It seems so far that all the required changes are shadow-related, because they're related to how the extension is built/packaged — in particular, by this namespace here. Is this right? And if so, should a patch be submitted?