feat(desktop): forward flags to underlying laufey executable

[iownbey]

#36031

Open to a different approach if you guys have any suggestions, but this seemed like a really simple way to unlock a lot of chromium functionality. I built and tested deno to check that this let me use this with hmr and the built executable

AI was used to write this PR

[deno-cla-assistant]

Deno Individual Contributor License Agreement

All contributors have signed the CLA. Thank you!

• @iownbey

Re-run CLA check

---

This is an automated message from CLA Assistant

[bartlomieju]

Thanks for this, and for the clear write-up in the issue — being unable to configure CEF is a real gap we want to close.

The concern with the current approach is that DesktopFlags::args already has a meaning: it's the trailing script argv, and it's baked into the compiled binary's metadata as Deno.args (cli/tools/desktop.rs:497 → cli/standalone/binary.rs:1031). Forwarding that same list to laufey means an app that takes its own arguments would have them leak onto the CEF command line in dev, and bare positionals could make laufey's arg parsing unhappy. It also only affects the HMR/inspector path, so a packaged app still can't be configured — which is the part of #36031 that actually blocks shipping.

Could we instead add a dedicated --backend-args flag whose value is forwarded verbatim to the laufey backend, leaving args as Deno.args? Something like:

deno desktop --hmr --backend-args="--use-gl=angle --enable-features=Vulkan" main.ts

Two things that would make it complete:

• Plumb it through the packaged/compiled path as well, not just run_desktop_hmr, so the switches survive into the shipped app. A desktop.backend.args key in deno.json would fit how identifier / deepLinks / codesignIdentity are already sourced.
• Warn (or ignore) on switches the CLI already manages — notably --remote-debugging-port, which collides with the LAUFEY_REMOTE_DEBUGGING_PORT the DevTools mux allocates when --inspect is set, and --runtime.

For tests, a spec test in tests/specs/ covering the flag parsing/forwarding would be more valuable than the unit test on Command::args. And a line in the deno desktop help text (desktop_subcommand() in cli/args/flags.rs) would cover the documentation half of the issue.

[iownbey]

Seeing if my draft passes ci. If it does I'll do a cleanup pass.
Wasn't completely sure what you wanted the deno.json api to look like, since the desktop.backend.args suggestion seemed a bit ambiguous as desktop.backend is a string currently. I currently have it using this:

"backend": "cef"
"backendArgs": {
  "cef": "..args..."
}

Let me know if you want to go with a different approach

[iownbey]

spec tests are failing in ci, not locally, looks like its related to virtual desktops. I'll be able to investigate more in a few days