From 7285a566dd75ec6869aef01947936721ef0ac5c8 Mon Sep 17 00:00:00 2001
From: Fabian Hamm <fabian.hamm@outlook.de>
Date: Tue, 8 Sep 2026 18:55:05 +0200
Subject: [PATCH] fix(wasm): select the bin target, so trunk emits a real
 bundle

`trunk build --release` reached the asset pipeline for the first time and
failed there:

  found more than one target artifact: ["sylpheed_viewer", "sylpheed-viewer"]

The crate declares both a [[bin]] `sylpheed-viewer` (src/main.rs) and a
[lib] `sylpheed_viewer` cdylib (src/lib.rs), and the index.html link named
neither, so trunk refused to guess.

Trunk's error offers two ways out and THEY ARE NOT EQUIVALENT. Measured,
both exiting 0:

  data-target-name="sylpheed_viewer"   1_478 bytes,        1 app symbol
  data-bin="sylpheed-viewer"          21_298_268 bytes, 2_998 app symbols

Selecting the lib "succeeds" while linking nothing, because there is no
wasm entry point in it -- no wasm-bindgen dependency, no import, no
`#[wasm_bindgen(start)]`. The linker drops the whole app and trunk emits an
empty module. That would have turned this job GREEN on a bundle that cannot
start, which is worse than the red it replaced.

`main()` is a valid wasm entry: it calls `sylpheed_viewer::run()` and its
only native-specific code is already `#[cfg(not(target_arch = "wasm32"))]`.
With the bin selected, trunk injects a real init -- `import init`, an
integrity-checked module preload, `__wbindgen_start`, and the
`TrunkApplicationStarted` event.

The lib.rs docs claimed this file was the WASM entry point "called from
`wasm_bindgen` init on the web". Nothing ever called it. That comment is
what made the lib look like the right target, so it is corrected here
rather than left to mislead the next reader.

Verified locally with trunk 0.21.7 on x86_64. The exit code does not
distinguish these two cases -- only the artifact does.

Refs #11
---
 crates/sylpheed-viewer/index.html | 2 +-
 crates/sylpheed-viewer/src/lib.rs | 8 ++++++--
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/crates/sylpheed-viewer/index.html b/crates/sylpheed-viewer/index.html
index d67d87ab..e1559e3f 100644
--- a/crates/sylpheed-viewer/index.html
+++ b/crates/sylpheed-viewer/index.html
@@ -186,7 +186,7 @@
     </div>
 
     <!-- Trunk injects the compiled WASM module here -->
-    <link data-trunk rel="rust" data-wasm-opt="z" />
+    <link data-trunk rel="rust" data-bin="sylpheed-viewer" data-wasm-opt="z" />
 
     <script>
         // Update loading status messages as WASM initializes
diff --git a/crates/sylpheed-viewer/src/lib.rs b/crates/sylpheed-viewer/src/lib.rs
index 48607390..0e2565ad 100644
--- a/crates/sylpheed-viewer/src/lib.rs
+++ b/crates/sylpheed-viewer/src/lib.rs
@@ -4,7 +4,11 @@
 //!
 //! This crate serves as both:
 //! - A **native binary** (via `main.rs`) — full desktop viewer
-//! - A **WASM library** (this file) — browser viewer at `index.html`
+//! - A **WASM app**, also entered through `main.rs` — browser viewer at
+//!   `index.html`. Trunk builds the *bin* target (`data-bin` in index.html) and
+//!   wasm-bindgen calls `main()`; there is no `#[wasm_bindgen(start)]` here and
+//!   this file is NOT the wasm entry point. Selecting the lib target instead
+//!   links an empty 1.4 KB module that still exits 0 — see #11.
 //!
 //! ## Architecture
 //! - `sylpheed_formats` handles all binary parsing — no Bevy dependency
@@ -42,7 +46,7 @@ impl Default for ViewerState {
 
 /// Build and run the viewer application.
 ///
-/// Called from `main.rs` on native and from `wasm_bindgen` init on the web.
+/// Called from `main.rs`, on both native and wasm.
 pub fn run() {
     let mut app = App::new();