fix(wasm): select the bin target, so trunk emits a real bundle
Some checks failed
CI / Native — linux (pull_request) Successful in 32m46s
CI / WASM — Web (pull_request) Failing after 23m39s
CI / Formatting (pull_request) Failing after 48s

`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
This commit is contained in:
2026-09-08 18:55:05 +02:00
parent 90365b1751
commit 7285a566dd
2 changed files with 7 additions and 3 deletions

View File

@@ -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

View File

@@ -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();