Running fresh from a deno Worker

[andykais]

I am attempting to use deno.land/x/webview + fresh as a local gui stack. I cannot run both the webview and fresh in the same process because webview.run() is a synchronous call. Macos requires any ui code to run in the main thread, so running the webview in a worker is out of the question webview/webview_deno#149. That leaves us with running fresh inside a web worker. That fails with the problem described below:

Fresh currently depends on preact dependencies which require the window variable to run. Attempting to run main.ts in a deno Worker results in this error.

error: Uncaught (in worker "") (in promise) TypeError: Cannot read properties of undefined (reading '__PREACT_DEVTOOLS__')
    at https://esm.sh/stable/[email protected]/denonext/devtools.js:2:166
error: Uncaught (in promise) Error: Unhandled error in child worker.
    at Worker.#pollControl (ext:runtime/11_workers.js:159:19)
    at eventLoopTick (ext:core/01_core.js:183:11)

It seems like window is specifically not part of the web worker spec, so this is expected. However it seems like at a certain point fresh was able to run in a worker webview/webview_deno#146. I am curious if this was ever an intended use case for fresh, and if there is a way to support it again.

[marvinhagemeister]

This sounds like esm.sh messed with the preact/devtools import. The source line where the error occurs looks like this:

export function initDevTools() {
	if (typeof window != 'undefined' && window.__PREACT_DEVTOOLS__) {
		window.__PREACT_DEVTOOLS__.attachPreact('10.17.1', options, {
			Fragment,
			Component
		});
	}
}

We have gotten some reports in the past that esm.sh changed that to typeof Deno != 'undefined' && window.__PREACT_DEVTOOLS__ which is obviously wrong. You can check if that's the case by appending ?target= es2022 to the preact entries in the import map.

[andykais]

actually the source line where the error occurs looks like this https://esm.sh/stable/[email protected]/denonext/devtools.js:

/* esm.sh - esbuild bundle([email protected]/devtools) denonext production */
import{options as o,Fragment as _,Component as a}from"/stable/[email protected]/denonext/preact.mjs";function r(n,t){return o.__a&&o.__a(t),n}typeof Deno  <"u"&&window.__PREACT_DEVTOOLS__&&window.__PREACT_DEVTOOLS__.attachPreact("10.15.1",o,{Fragment:_,Component:a});export{r as addHookName};
//# sourceMappingURL=devtools.js.map

adding target=es2022 didnt seem to change the result https://esm.sh/stable/[email protected]/denonext/devtools.js?target=es2022. I see you added the label upstream. Should I open this issue in the preact repo?

I think this is the source line you are referring to https://github.com/preactjs/preact/blob/7748dcb83cedd02e37b3713634e35b97b26028fd/devtools/src/devtools.js#L3, but I do not see where deno gets referenced, it seems like there is another source for the denonext release that I cant quite find

[marvinhagemeister]

It's an upstream issue in esm.sh not in Preact. By default, when you do a fetch() call in Deno, it will add the Deno user agent to the request. esm.sh then does something nasty and based on the user agent it serves you a completely different file compared to what you'd get if you'd access the same URL in the browser. Whenever the denonext segment is in the esm.sh URL, then it means that it sniffed the Deno user agent and redirected to their deno transpiled version. Problem is that their deno compile pass is very buggy when it comes to the window object.

Case in point: The code you linked to is the minifed variant of the original source. In the source we have typeof window != "undefined" && window.__PREACT_DEVTOOLS__ as the condition. And in the minifed code you linked to that has been rewritten to: typeof Deno <"u"&&window.__PREACT_DEVTOOLS__ which is very wrong.

So yeah, this is an upstream issue in esm.sh and the only workaround so far is to pass ?target=es2022 to force esm.sh to use that instead of their deno target. Note that this must be applied to the original URL. You cannot rewrite an already rewritten denonext file to something else in esm.sh.

So in your import map add this line:

{
  "imports": {
    "preact/devtools": "https://esm.sh/[email protected]/devtools?target=es2022"
  }
}

[marvinhagemeister]

Closing as it's a bug in esm.sh . With recent changes preact can be pulled in from npm: which doesn't have these kinds of issues.