deno: `deno compile` does not have web worker support

This is a tracking issue to investigate how we can support web workers in deno compile.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 69
  • Comments: 16 (4 by maintainers)

Most upvoted comments

Just want to bump this, I’ve been working on an project that doesn’t use just one, but two workers 😅 It’s the foundation for working on a desktop app using webview_deno, and using a worker to serve the page, assets, and a websocket connection from an oak-based web server. The second worker runs a long-running subprocess. I compile the static web assets into binaries using denobundle so they can be bundled with the binary. This is the best way so far I’ve found to build a GUI with deno. Just need the final step of wrapping it all together!

Definitely not ready for widespread use yet, but it’s a simple GUI for managing Docker containers.

https://github.com/jcs224/dockersaurus

This feature would be a great addition and allow us to use the standalone binary since web workers is one of our requirements. Encoding the worker modules as data: URLs would work great if possible.

+1 to this. could base64 be a first step?

new Worker(
  "data:application/typescript;base64,Y29uc29sZS5sb2coImhlbGxvIHdvcmxkIik7CnNlbGYuY2xvc2UoKTs=",
  { type: "module" },
);
thread 'deno-worker-0' panicked at 'not yet implemented: Worker are currently not supported in standalone binaries', cli/standalone.rs:163:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: RecvError', runtime/ops/worker_host.rs:522:46
fatal runtime error: failed to initiate panic, error 5
Aborted (core dumped)

Just tried this with 1.32, works now! I think this can be closed now, per https://github.com/denoland/deno/pull/17657

Is this supposed to be working now using data:-urls? Can’t seem to get it to work

With deno compile, all module fetching and Typescript compilation happens at compile time, so you can be sure that remote imports haven’t changed under the hood, for example. With regular imports, the whole module graph can be tracked, fetched and transpiled at compile time. However, with workers, the worker’s main module is given as a string which might be built up at runtime, and combined with other factors it means it’s not easy to statically analyze a worker’s main module at compile time.

Starting in 1.32, deno compile has an --include flag which lets you specify additional modules which will be fetched and transpiled at compile time, along with their imports, recursively. You can use it as deno compile --include ./worker1.ts --include ./worker2.ts --output compile main.ts

As for data: URLs, Deno doesn’t support Typescript with them, so they can work without being in the module map at compile time. But if the data: URL imports another (non-data:) module, that module will need to be in the module graph.