Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

deno compile does not have web worker support #8654

Closed
lucacasonato opened this issue Dec 7, 2020 · 16 comments
Closed

deno compile does not have web worker support #8654

lucacasonato opened this issue Dec 7, 2020 · 16 comments
Labels
cli related to cli/ dir suggestion suggestions for new features (yet to be agreed) user feedback wanted feedback from the community is desired

Comments

@lucacasonato
Copy link
Member

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

@lucacasonato lucacasonato added cli related to cli/ dir suggestion suggestions for new features (yet to be agreed) user feedback wanted feedback from the community is desired labels Dec 7, 2020
@Zizaco
Copy link

Zizaco commented Feb 26, 2021

+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)

@adamdbradley
Copy link

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.

@bartlomieju
Copy link
Member

Ref for a PR #9936

@authcompanion
Copy link

@lucacasonato would you have any updates on how you're thinking on this! tyvm.

@mweichert
Copy link

Ref for a PR #9936

@bartlomieju even with data URIs, workers don't seem to be available yet in compiled binaries.

@pokatomnik
Copy link

pokatomnik commented Jul 7, 2022

This would be the most wanted feature since compilation has been implemented.
Base64 is a good workaround, but it requires an additional build step.

@jcs224
Copy link

jcs224 commented Aug 11, 2022

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

@pokatomnik

This comment was marked as off-topic.

@jcs224
Copy link

jcs224 commented Mar 23, 2023

Just tried this with 1.32, works now! I think this can be closed now, per #17657

@Hexagon
Copy link

Hexagon commented Apr 17, 2023

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

@andreubotella
Copy link
Contributor

andreubotella commented Apr 17, 2023

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.

@Hexagon
Copy link

Hexagon commented Apr 17, 2023

That clears it up, thanks! 👍

@cowboyd
Copy link

cowboyd commented Sep 15, 2023

Curious what the reasons are to not implement this. Development resources? Security Concerns? Architectural concerns?

@lucacasonato
Copy link
Member Author

It's supported now

@cowboyd
Copy link

cowboyd commented Sep 17, 2023

Is there any chance that workers could be created without knowledge of the worker module at compile time? Specifically, I'm wondering if this feature might evolve into a safe alternative to #18327 since it allows for restricting permissions.

@lucacasonato
Copy link
Member Author

lucacasonato commented Sep 18, 2023

Refer to #18327 for more discussion on that. If that lands, it will naturally work for Worker too

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cli related to cli/ dir suggestion suggestions for new features (yet to be agreed) user feedback wanted feedback from the community is desired
Projects
None yet
Development

No branches or pull requests