Innei a608bd3f1d 🐛 fix(python-interpreter): run the worker as classic, and publish workers where a page can load them (#18277) ...

* 🐛 fix(python-interpreter): construct the worker as classic, not a module

The worker was constructed with `type: 'module'` while the bundler emits it
as an IIFE, so the declared type never matched the output. It also loads
Pyodide through `importScripts`, and a module worker rejects that call:

    TypeError: Failed to execute 'importScripts' on 'WorkerGlobalScope':
    Module scripts don't support importScripts().

The failure lands inside `init()`, so nothing surfaces until the interpreter
is first used — construction succeeds and the tool then fails on its first
real call.

Verified end to end in a browser against the built worker: Pyodide loads,
`print("hello from", sys.platform)` writes `hello from emscripten`, and
`6*7` returns 42.

* ✨ feat(build): publish web workers to the public root

`new Worker(url)` only accepts a same-origin script — no CORS header lifts
that, unlike a crossorigin script tag. So once the SPA's assets move to an
asset host, workers are the one thing that has to stay behind, served from
the page's own origin.

The build emits them into `app-workers/`, but `copyDirs` is an allowlist and
did not carry the directory across, so the files reached neither `public/`
nor the asset upload and the emitted URL resolved to nothing.

Copy them to `public/app-workers/` rather than into each SPA directory: the
files are byte-identical across variants, so one path keeps one copy and
gives the origin a single prefix to recognise.

2026-08-14 01:28:22 +08:00

..

src

🐛 fix(python-interpreter): run the worker as classic, and publish workers where a page can load them (#18277)

2026-08-14 01:28:22 +08:00

package.json

…

vitest.config.mts

…