You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed something weird while working on Gustwind, my Deno based tool meant for creating websites.
To make the approach more flexible, I began to leverage import() to fetch remote resources (in this case, components and their code). For performance purposes, the tool leverages web workers.
It seems this particular combination is triggering some behavior in Deno that's not exactly expected as it seems that during a build it's fetching remote resources separately each time for each worker instead of leveraging a shared cache. I understand there's some potential for a race condition there but at least after the first import() that completed I would expect it to be fast at least on a subsequent build.
I set up a branch to show the issue. If someone wants to check it, here's how to do it:
If you want, I can try to come up with a greatly simplified example but I thought to open this issue to see if it's expected behavior instead of a bug. I suppose I could try to avoid import() and go with fetch() and my own approach instead but the problem there is that I would have to pull dependencies as well (doable but it's some work since this implies AST introspection and traversing a dependency graph and caching everything. Now Deno is doing all the work for me).
The text was updated successfully, but these errors were encountered:
I noticed something weird while working on Gustwind, my Deno based tool meant for creating websites.
To make the approach more flexible, I began to leverage
import()
to fetch remote resources (in this case, components and their code). For performance purposes, the tool leverages web workers.It seems this particular combination is triggering some behavior in Deno that's not exactly expected as it seems that during a build it's fetching remote resources separately each time for each worker instead of leveraging a shared cache. I understand there's some potential for a race condition there but at least after the first
import()
that completed I would expect it to be fast at least on a subsequent build.I set up a branch to show the issue. If someone wants to check it, here's how to do it:
deno task build
The builder code is located at https://github.com/gustwindjs/gustwind/tree/worker-import-bug/gustwind-builder and the loader is at https://github.com/gustwindjs/gustwind/blob/worker-import-bug/utilities/loaders.ts (this is doing
import()
).If you want, I can try to come up with a greatly simplified example but I thought to open this issue to see if it's expected behavior instead of a bug. I suppose I could try to avoid
import()
and go withfetch()
and my own approach instead but the problem there is that I would have to pull dependencies as well (doable but it's some work since this implies AST introspection and traversing a dependency graph and caching everything. Now Deno is doing all the work for me).The text was updated successfully, but these errors were encountered: