Deno Desktop - How to combine win.binding with framework autodetection?

[8]

When reading the docs, I see 2 separate options:

1. create custom entry point with a handler eg. deno desktop desktop.ts
2. use the framework autodetection to package and launch your app eg. deno desktop

Option 1 allows to add bindings to supply deno functions to access the filesystem, etc.
Option 2 allows the bundling of all files and support for hot module reload in devmode, etc.

Now for a real application I want to combine that, but from the documentation it's not clear for me how to do that.

So my question is how can I add a some startup wrapper code that executes in deno's context (having access to the Deno.BrowserWindow() etc) so that I can bind functions that will be later available for the autodected application before handing it over to the framework auto-detection for the handler?

Thank you!

Take care,
Martin

[lMysticl]

The exact combination is not currently exposed by the CLI.

deno desktop . generates a synthetic entry point and controls framework startup. Passing desktop.ts explicitly opts out of framework autodetection.

If you need bindings, the supported approach is an explicit entry:

const win = new Deno.BrowserWindow();

win.bind("myBinding", () => {
  // ...
});

// Import and start the framework server here.

You then own the framework server startup and build output. Framework HMR will only work if the server you start provides it.

So there is currently no hook for registering bindings before handing control back to the auto-generated framework entry.

[Charlie284]

There isn't currently a general startup-wrapper hook that can be composed with framework auto-detection.

Framework detection only runs when the source is .. Supplying desktop.ts switches to explicit-entrypoint mode:

• Detection requires source_file == "."
• Framework HMR starts the dev server separately
• The desktop runtime receives a no-op entrypoint in that mode

Therefore, during detected-framework HMR, there is no user-owned Deno startup module in which to register win.bind().

For now, use an explicit entrypoint and start the framework server or handler yourself:

const win = new Deno.BrowserWindow();

win.bind("readFile", async (path: string) => {
  return await Deno.readTextFile(path);
});

// This module must start the framework/server integration.
await import("./server.ts");

deno desktop --hmr desktop.ts

The first Deno.BrowserWindow() adopts the startup window. This gives you plain-app Deno-side HMR, but not the automatically detected framework dev-server behavior.

There is one framework-specific exception in production: for example, Vite SSR detection imports an existing server.ts, so binding registration can live there. Under detected-framework HMR, however, that production entrypoint is replaced by the no-op module.

A bootstrap/preload option imported by both the generated production entrypoint and the framework-HMR runtime would be needed to support this generically.

[8]

Thank you guys for the quick answer!

I feared that I needed to do the manual route.
Double thanks for the link to the detect_vite() so I can read up how the sausage gets made :)

Take care,
Martin