How should BrowserWindow bindings be registered when using deno desktop --hmr . with Next.js?

[kantbtrue]

Hi! I'm building a Next.js application with Deno Desktop and I'm trying to understand the recommended way to expose desktop APIs to the webview.

I can successfully start the application using:

deno desktop --hmr .

Following the bindings documentation, I tried creating a BrowserWindow and registering bindings:

const win = new Deno.BrowserWindow();

win.bind("setTitle", (title: string) => {
  win.setTitle(title);
});

However, in framework mode (deno desktop --hmr .), this file is never executed, and in the webview:

await bindings.setTitle("Dashboard");

results in:

ReferenceError: bindings is not defined

From reading the documentation, bindings are registered per BrowserWindow, which makes sense. My confusion is about framework mode:

deno desktop . automatically creates the application window.
The bindings examples assume I create the BrowserWindow myself.
I couldn't find documentation explaining how these two approaches work together.

What is the recommended way to:

Register bindings when using the built-in Next.js integration?
Access or customize the automatically created BrowserWindow?
Execute custom desktop initialization code (menus, bindings, tray, etc.) in framework mode?

If this isn't currently supported, I'd be happy to help improve the documentation once I understand the intended architecture.

Thanks!

[Blatman]

Deno 2.9.2

Haven't got an answer but getting the same thing.

win.bind("openPdfWin", ({id: number}) => {
// new Deno.BrowserWindow etc
})

await bindings.openPdfWin('id: 0');

I get bindings is not defined although the docs suggest that bindings is exposed by default.

If I specify something like const bindings = 'bindings'; then I get bindings.openPdfWin is not a function

Just seems to be no way to call the win.bind process.

[barry166]

From the current desktop code, the binding has to be registered from Deno-side code that is actually executed, not from the Next/browser bundle.

The built-in framework path creates the initial native window first, then the first new Deno.BrowserWindow() in the Deno runtime wraps that existing window. So this shape is correct, but it must live in the desktop entrypoint, or a module imported by it, before the page calls the binding:

const win = new Deno.BrowserWindow();

win.bind("setTitle", (title: string) => {
  win.setTitle(title);
});

In the webview, call it as globalThis.bindings.setTitle(...) / window.bindings.setTitle(...); in a Next/ES module, bare bindings is not a declared variable.

I don't see a documented hook in the auto-detected Next framework mode for "run this desktop setup module". If you need menus/tray/bindings today, use an explicit desktop entrypoint that starts Next and also registers the bindings, instead of relying on deno desktop . to generate the entrypoint for you.

[kantbtrue]

Thanks, that makes sense and it aligns with what I'm seeing.

I added logging to my main.ts, but it never executes when running:

deno desktop --hmr .

As a result, win.bind(...) is never called, and window.bindings is undefined in the webview.

My main confusion is around the "explicit desktop entrypoint" you mentioned. Is there currently a supported way to configure one while still using the built-in Next.js framework integration, or does that mean replacing the framework launcher entirely and starting Next.js ourselves before creating the BrowserWindow?

I'm mainly trying to understand the recommended architecture for apps that need bindings, menus, tray, and other desktop APIs.