docs(#754): desktop consumer = Deno desktop runtime; remove Tauri; D1–D3 plan + spike#775
Merged
Merged
Conversation
…spike scaffold Resolves the open question in phase-1.md §10 (how the desktop build consumes the TanStack app after cutover). Direction: ship the desktop app as the same TanStack Start app wrapped by the Deno desktop runtime (auto-detects TanStack Start; reuses the host-portability seam), not a revived Tauri. Ships after #13 cutover; Deno desktop is canary today. - docs/migration/desktop-deno-runtime.md: full analysis — current Tauri-dormant state, why Deno desktop over Tauri, the local-vs-remote-server (secrets) decision (default to the hybrid shape), and open questions for a spike. - phase-1.md §10 + strategy.md: point the open question at the new doc; add a post-#13 deferred follow-up entry and a Links reference. - scripts/spikes/deno-desktop/: throwaway spike — Stage 1 native-window smoke (deno desktop), Stage 2 headless host-seam fall-through check (serverEnv → process.env, cache → memory backend on Deno). Excluded from tsconfig + biome (throwaway Deno code, not part of the Node app). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Ss1ey8VzR6m53j734ji3fx
…undle bloat caveat) Installed Deno canary and actually ran the spike. Findings folded back into the doc + README: - Seam fall-through PASS on Deno: serverEnv() reads process.env, cache picks the memory backend — host seams need zero Deno-specific code (only the cloudflare:workers import needs aliasing, as TARGET=vercel already does). - `deno desktop` subcommand exists on canary and compiles a bundle; framework auto-detect confirmed. - Reality-checks vs the marketing: the canary reports 2.8.3+<hash> (not the documented 2.9.0), and on Linux the default backend is CEF/Chromium → a ~1.7 GB bundle (libcef.so ~1.5 GB), undercutting the "small binaries" pitch. Recommendation tempered: bundle size on macOS/Windows is now a decision gate before committing over Tauri. Spike hardening: run.sh gates Stage 1 on the subcommand's presence (not a version number), makes the heavy CEF build opt-in (--build), and always runs the cheap headless Stage 2. Added a .gitignore backstop so the ~1.7 GB build dir can never be committed. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Ss1ey8VzR6m53j734ji3fx
… .app (not Tauri-small) Ran Stage 1 on a real macOS arm64 device (the cloud sandbox was headless): `deno desktop` built a signed Hello.app, launched it, and the window rendered (screenshot-verified). Process tree is full Chromium multi-process. Decisive finding: macOS uses CEF/Chromium too, NOT native WKWebView. Hello-world .app = 295 MB (225 MB is the Chromium Embedded Framework) — Electron-class, not Tauri-class. So the "small binaries like Tauri" pitch is false on BOTH platforms tested (Linux ~1.7 GB, macOS 295 MB). Recommendation updated from "lean toward Deno desktop" to an explicit DX-vs-size tradeoff: Deno desktop wins on all-TS DX + TanStack auto-detect + the verified host-portability seam, but loses Tauri's small-binary advantage. Tauri stays the pick if a small native binary is a hard requirement. Still canary/experimental; still parked behind #13 cutover. Synced phase-1.md §10 + strategy.md pointers and the spike README findings to match. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Ss1ey8VzR6m53j734ji3fx
…backends (webview vs cef) Followed up on the docs: `deno desktop` supports `--backend cef|webview|raw` (and `desktop.backend` in deno.json). My 295 MB measurement was the CEF backend specifically — which the canary silently defaulted to, despite the docs saying the native `webview` backend is default (another canary-vs-docs drift; pin it). So the earlier "no small-binary advantage / Electron-class, period" conclusion was wrong: it was CEF-only. The native `webview` backend promises Tauri-like size from the same codebase — UNTESTED here, and it carries the classic native-webview catch (per-OS rendering/feature inconsistency, no DevTools), which herocast's heavy UI (TipTap, HLS embeds, wallet) is sensitive to. Net: Deno desktop's real edge is that ONE codebase spans both size tiers (webview small / cef consistent). Recommendation upgraded to "leading candidate," with `--backend webview` against herocast's real UI flagged as THE gating probe. Synced desktop-deno-runtime.md, phase-1.md §10, strategy.md, and the spike README. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Ss1ey8VzR6m53j734ji3fx
…op + proof-driven D1–D3 plan Desktop direction is decided: wrap the TanStack app in the Deno desktop runtime, backend pinned to `cef` (rendering fidelity; binary size deprioritized per product call). Tauri is removed — it was already dormant (no src-tauri, no deps). Repo cleanup: - .github/workflows/build.yaml: drop all commented Tauri/Rust steps + the Tauri-era OS matrix (now plain ubuntu-latest: checks + Sentry release). - CLAUDE.md: replace the stale "Desktop App (Tauri)" section (rls scripts that no longer exist) + tech-stack/deploy mentions → point at the Deno desktop doc. - CONTRIBUTING.md "Run as a Native App": Tauri → Deno desktop direction. - .gitignore: drop the "# tauri output" label (keep build/ ignored). Doc rewrite (desktop-deno-runtime.md): remove the Tauri comparison and the size-as-gate framing; reframe as a clean, proof-driven plan with 3 sequential follow-up issues to bring desktop to users: - D1 "it runs": TARGET=deno build + real app boots in a desktop window (proof: screenshot of /feeds rendering real casts; CF build stays green). - D2 "it's correct & secure": hybrid server (server fns proxy the remote worker so secrets never ship) + OS-keychain key custody (proof: grep bundle = no secrets; live login + post; keys not in IndexedDB). - D3 "it's shippable": code-sign/notarize + deep-link auth callback + auto-update (proof: a non-dev downloads/installs/logs in; update applies + rolls back). Gated on #13 cutover + deno desktop leaving canary. Synced phase-1.md §10 + strategy.md to match. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Ss1ey8VzR6m53j734ji3fx
Cross-reference the three desktop follow-up issues from the plan doc, strategy.md, and phase-1.md §10 so the proof-driven sequence is tracked against the epic. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Ss1ey8VzR6m53j734ji3fx
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What & why
Resolves the open desktop-consumer question parked in
phase-1.md §10("how does the desktop build consume the TanStack app after cutover"). Decision: wrap the migrated TanStack Start app in the Deno desktop runtime — the desktop app is the TanStack app, no separate consumer shim. The dormant Tauri integration is removed.This PR is docs + repo cleanup + a throwaway spike — no app/runtime code changes. Desktop execution is deferred until after #13 cutover and tracked as three follow-up issues (below).
Spike — what was actually verified (not from marketing)
serverEnv()→process.env, cache → in-process memory backend. Only thecloudflare:workersimport needs aliasing, whichTARGET=vercelalready does → Deno is a build-target swap, not a rewrite.deno desktopbuilds + launches + renders end-to-end on macOS (hello-world; window screenshot-verified; full Chromium multi-process under thecefbackend).2.8.3+<hash>(not the documented2.9.0); it silently defaulted to thecefbackend → pindesktop.backend. Size is--backend-selectable (cef≈ 295 MB macOS for rendering fidelity; nativewebviewis a later size optimization). Size is deprioritized for now.Repo cleanup (Tauri removal)
.github/workflows/build.yaml: drop all commented Tauri/Rust steps + the Tauri-era OS matrix → plainubuntu-latest(checks + Sentry).CLAUDE.md: replace the stale "Desktop App (Tauri)" section (rlsscripts that no longer existed) + tech-stack/deploy mentions → point at the new doc.CONTRIBUTING.md,.gitignore: de-Tauri'd. (Nosrc-tauri/, no Tauri deps existed.)Plan — proof-driven follow-ups (all post-#13 cutover)
deno desktop(TARGET=deno build) #772 — D1 "it runs":TARGET=denobuild + real app boots in a desktop window.Files
docs/migration/desktop-deno-runtime.md(the plan),scripts/spikes/deno-desktop/(throwaway spike — excluded fromtsconfig/biome).phase-1.md §10,strategy.md(deferred follow-ups + links).Part of epic #754.