Problem

A deno desktop-compiled app that fails while loading or first evaluating its main module exits silently — the window blinks open for ~1s and closes with no error anywhere. This is the report in #35544 (and the reason the reporter, a workspace/monorepo user, couldn't tell what was wrong: "No logs anywhere — if there is a way to enable/view logs anywhere, please let me know").

Root cause

When the main module fails to load/instantiate/first-evaluate (a failed import, a link error, a top-level throw/await rejection), LibMainWorker::run() returns Err, which propagates to the laufey::main! handler in cli/rt_desktop/lib.rs. That handler showed a native error dialog only for non-JS errors (if !is_js_error), on the assumption that "JS errors are already handled by the error reporting JS listener."

That assumption is false for the load phase. The app's global error / unhandledrejection listeners (installed by desktop_error_reporting_js) only fire for events dispatched during the event loop. A module that fails before the loop starts is observed by nobody: the Rust side suppressed the dialog, and the only output was a log::error! to a stderr that a Finder/Dock-launched app can't see. → silent exit.

(Post-load runtime errors are unaffected: those do reach the JS listener, which shows a dialog.)

Fix

• cli/rt/run.rs: add DesktopStartupError (carries a pre-formatted, user-facing message) and a new else if has_desktop run branch that mirrors LibMainWorker::run() but tags the preload/main-module/load-event phase errors. Plain deno compile (else) is unchanged.
• cli/rt_desktop/lib.rs: the handler downcasts to DesktopStartupError and uses should_show_native_error_dialog(is_startup, is_js_error) so startup failures (and non-JS crashes) always get a native dialog, while post-load JS errors are still left to the app's own listeners (no duplicate dialog).
• Unit tests in both crates.

Note on "workspace"

The issue is framed as a workspace problem, so I checked that first: I built deno + libdenort locally and confirmed that generic cross-workspace member imports resolve correctly in a compiled desktop binary (a minimal 2-member workspace where pkg-a imports @test/b by name compiles, resolves the member, opens the window, and exits cleanly). The serialized workspace resolver is shared between deno compile and deno desktop. The real, generalizable bug behind "blinks open and closes" is the swallowed startup error — once it's surfaced, an app-specific failure (e.g. a workspace member that can't find its bundled assets at runtime) becomes diagnosable instead of invisible.

Verification

Built cargo build --bin deno + cargo build -p denort_desktop, compiled a desktop app against the local runtime (DENORT_DESKTOP_BIN), and confirmed:

• happy path still runs (window created, clean exit);
• a previously-silent startup error (failed import / link error) now surfaces — the process blocks on the native "Application Error" dialog instead of vanishing.

cargo test -p denort -p denort_desktop green; cargo clippy clean; cargo fmt.

Refs #35544

Closes denoland/divybot#611