deno

Fixes #36503. Every desktop packaging path hard-coded its metadata: the macOS bundle always claimed 1.0.0, the // installers always claimed version 1.0.0, and the License tag always said MIT regardless of the project's actual license. The workspace root deno.json field (already baked into the binary as for auto-update) now feeds the macOS Info.plist, , and versions, and its field (when a string) feeds the License tag. Format quirks are handled per packager: deb/rpm: semver prerelease maps to (both formats order before the release, matching semver intent); MSI: reduced to the numeric form it requires (prerelease/build suffixes dropped); plist: carried verbatim. Defaults are unchanged when nothing is configured. There's no standard deno.json field for authors/maintainer, so the Maintainer / Vendor stay synthesized from the app name — if that matters to the reporter it'd need a new config field, which can be a follow-up. Covered by a new test building an actual with a configured version + license, plus edge cases; all existing packaging tests pass unchanged (defaults preserved). https://claude.ai/code/session_016w9C7umSW1KUYa7eXwSXRo

Fixes #36092. Under (and anything else that sets ) the first call must listen on the runtime-assigned address so the webview knows where to navigate — but an explicit option was silently replaced, so apps printed and expected a URL that nothing was listening on: Now, when the override replaces an explicitly-configured different port, a warning makes the mismatch visible: No warning when no port was given, when was requested, or when the ports happen to match. Verified with a desktop run of the issue's snippet. https://claude.ai/code/session_016w9C7umSW1KUYa7eXwSXRo

Summary Follow-up to #35501, which #35541 (merged 2026-06-29) partially fixed. The default window title is no longer , but the value used as the "baked app name" appears to be the compiled runtime library's filename, including its extension — so a app configured as titles its window: macOS: Windows: — a second, Windows-only bug truncates the title to its first character. Additionally, #35541's description says "a page that sets still overrides the title at the OS level" — we cannot reproduce that on macOS. Setting (in inline script, on DOMContentLoaded, and on a delayed timer) changes the DOM value but the OS window title never updates. Version Observed on deno canary ; also tested with canary (which includes #35541). macOS 26.5.2 (25F84) (Tahoe) arm64; Windows 11 x64 (WebView2). App built with + desktop bundling ( unstable feature); the runtime library in the emitted bundle is named / , matching the observed title. Steps to reproduce 1. Start from the Hello Desktop example. 2. In , set . 3. Serve a page whose HTML has and which also sets after load. 4. Build for macOS and Windows; run the packaged app. Expected: window title on both platforms (from the baked app name, or overridden by per #35541). Actual: macOS title is ; Windows title is . Changing at runtime has no effect on the macOS OS-level title. What we ruled out is set and correct (the bundle/artifact names honor it). Page `document.titleDeno.BrowserWindowBrowserWindowuser32.dllEnumWindowsSetWindowTextWdesktop.app.namedocument.titleDeno.BrowserWindow`. We can test candidate fixes on both platforms, please let me know.