Skip to content

fix: resolve MuPDF wasm correctly in desktop dev - #126

Merged
delibae merged 2 commits into
delibae:mainfrom
WhiskyChoy:codex/dev-mupdf-wasm-fix
Apr 7, 2026
Merged

delibae merged 2 commits into
delibae:mainfrom
WhiskyChoy:codex/dev-mupdf-wasm-fix

Conversation

@WhiskyChoy

Copy link
Copy Markdown
Contributor

Summary

  • point MuPDF's wasm loader at Vite's /@fs/ path during desktop dev so the worker fetches the real .wasm binary
  • keep packaged and production builds unchanged by applying the override only in import.meta.env.DEV
  • declare the injected wasm path constant in Vite config and worker typings

Why

In local desktop dev, the MuPDF worker can request mupdf-wasm.wasm through a path that falls back to index.html, which then crashes WebAssembly instantiation with an invalid magic word. Resolving the wasm through Vite's filesystem serving path keeps the dev worker on the actual binary while leaving release builds untouched.

Validation

  • pnpm --filter @claude-prism/desktop build
  • manual verification on Windows desktop dev: PDF preview loads again after compilation
  • checked the dev wasm URL directly and confirmed it returns 200, Content-Type: application/wasm, and the expected 00 61 73 6d header

Notes

  • I could not run a native macOS build in this environment
  • based on Vite's documented /@fs/ dev serving behavior, the dev-only path override should remain compatible with macOS as long as the local filesystem path is allowed by the dev server

Copilot AI review requested due to automatic review settings April 7, 2026 08:05

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR fixes MuPDF WebAssembly loading in the desktop app during local Vite dev by forcing the worker to fetch the real mupdf-wasm.wasm via Vite’s /@fs/ filesystem-serving path, avoiding the index.html fallback that breaks WASM instantiation. Production/packaged behavior is kept unchanged by applying the override only when import.meta.env.DEV is true.

Changes:

  • Inject an absolute filesystem path for mupdf-wasm.wasm into the Vite bundle via define.
  • Configure the MuPDF worker to override Emscripten’s locateFile in dev to return a /@fs/... URL for the WASM binary.
  • Add global TypeScript typings for the injected constant.

Reviewed changes

Copilot reviewed 2 out of 3 changed files in this pull request and generated no comments.

File Description
apps/desktop/vite.config.ts Computes the MuPDF .wasm absolute path and injects it as __MUPDF_WASM_FS_PATH__ for Vite builds.
apps/desktop/src/vite-env.d.ts Declares the injected __MUPDF_WASM_FS_PATH__ constant for TypeScript.
apps/desktop/src/lib/mupdf/mupdf-worker.ts Sets $libmupdf_wasm_Module.locateFile in dev to resolve the WASM via /@fs/, then dynamically imports mupdf.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@delibae
delibae merged commit 7ea1bd8 into delibae:main Apr 7, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants