Stream: jco

Topic: ✔ policy on deno support


view this post on Zulip Yoshua Wuyts (Oct 18 2023 at 13:15):

I'm looking at https://github.com/bytecodealliance/jco/issues/167, and it seems that we're doing something slightly unoptimal for the deno runtime.

So what I'm wondering is: do we care about deno? Is it something we're maybe interested in supporting better later? Or is that out of scope for jco in its entirety?

If we care abou deno, or think we might care later, I'll tag the issue with a new target-deno label so we can start to track it. If we don't care about supporting deno, I think we should say as much and close the issue.

When using deno, most of the package files are resolved on the first run and cached. As jco is loading the wasm file through fetch, it will make a network request on each execution. Solutions like ...

view this post on Zulip Yoshua Wuyts (Oct 18 2023 at 13:16):

Ah, https://github.com/bytecodealliance/jco/issues/168 also seems deno-specific.

The following code generate some likely invalid values: export { core, runtimes, utils, core as "metatype:typegraph/core", runtimes as "metatype:typegraph/runtimes", utils as "metatype:typegraph/ut...

view this post on Zulip Milan (Oct 18 2023 at 16:28):

From the gallery Deno support would be nifty since it has decent sandboxing unlike node so far

view this post on Zulip Ralph (Oct 18 2023 at 18:35):

I'd vote for tagging those things; ultimately, with the intention of engaging those items at some point with deno peepz?

view this post on Zulip Guy Bedford (Oct 18 2023 at 19:21):

Agreed 100% we should support Deno, and we very much do support it. Wasm caching is something Deno should do natively though I think.

view this post on Zulip Yoshua Wuyts (Oct 18 2023 at 19:41):

Oki, I’ll tag the issues then. Thank you!

view this post on Zulip Notification Bot (Oct 18 2023 at 19:41):

Yoshua Wuyts has marked this topic as resolved.


Last updated: Oct 23 2024 at 20:03 UTC