Can't get correct `base` value in Web Worker

[ssssota]

Describe the bug

Can't get correct base value in Web Worker.

I configured kit.paths.base in svelte.config.js.

I can't get base path when I use web worker with vite feature (like import TestWorker from '../worker?worker')
in dev mode, production mode, and prerender time.

base always returns "" (empty string) in web worker.

Reproduction

https://github.com/ssssota/sveltekit-worker-incorrect-base

live demo: https://ssssota.github.io/sveltekit-worker-incorrect-base/

Logs

No response

System Info

sveltekit-worker-incorrect-app-module on  main is 📦 v0.0.1 via ⬢ v14.17.0 on ☁️  ap-northeast-1 took 3s
❯ npx envinfo --system --binaries --browsers --npmPackages "{svelte,@sveltejs/*,vite}"

  System:
    OS: Windows 10 10.0.19042
    CPU: (12) x64 AMD Ryzen 5 2600 Six-Core Processor
    Memory: 7.41 GB / 15.93 GB
  Binaries:
    Node: 14.17.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.11 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 7.20.2 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: 94.0.4606.71
    Edge: Spartan (44.19041.1023.0), Chromium (94.0.992.38)
    Internet Explorer: 11.0.19041.1202
  npmPackages:
    @sveltejs/adapter-static: ^1.0.0-next.20 => 1.0.0-next.20
    @sveltejs/kit: ^1.0.0-next.180 => 1.0.0-next.180
    svelte: ^3.43.1 => 3.43.1

Severity

serious, but I can work around it

Additional Information

src/service-worker.js can't import $app/paths with build errors

[Rich-Harris]

This is a tricky one. In the paths.js module, base is initialised to "", and it's only once the app boots that it gets set to the correct value:

kit/packages/kit/src/runtime/paths.js

Lines 1 to 11 in c394362

	/** @type {string} */
	export let base = '';
	/** @type {string} */
	export let assets = '';
	/** @param {{ base: string, assets: string }} paths */
	export function set_paths(paths) {
	base = paths.base;
	assets = paths.assets || base;
	}

Since the worker gets a different copy of the module than the main thread, the set_paths call doesn't affect the worker copy.

To be honest I'm not sure what a good solution to this would be. For now I think working around it by passing a message to the worker from the main thread is the best answer.