fix(web): give the browser build a load_file to fail through

Reading a drawing by path is gated off on wasm, and two features added
since 0.9.3 call it unconditionally: importing a drawing as a block, and
taking layer standards from one. Both compile into the web build, so the
web bundle stopped building and the v0.9.4 Pages deploy failed.

Neither feature can work in the browser — a file arrives through the page,
not from a filesystem the app can open — so the fix is not to make them
work but to let them say so. `load_file` now exists on wasm and returns
that as its error, which both callers already surface. Keeping the
signature means neither has to know that the web has no files, and the
next feature that reads a second drawing will not break the bundle
either.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Hakan SevenandClaude Opus 5 committed 2026-08-08 03:34:57 +03:00
1 parent 17b2f158f4
commit 6ca4463a26
3 files changed
+15

No files matched your search

+1
View File
@@ -53,6 +53,7 @@ pub(super) fn message_id(source: &str) -> Option<&'static str> {
" ⚠ No closed boundary found." => Some("catalog-no-closed-boundary-found-7a55b25ecb"),
" (%{count} objects)" => Some("catalog-count-objects-83518eccc2"),
" [Edge: Extend]" => Some("catalog-edge-extend-90a0cb9b4f"),
"Opening a drawing by path is not available in the browser." => Some("catalog-opening-a-drawing-by-path-is-not-available-in-be27bd71d4"),
"Prefix" => Some("catalog-prefix-90eceb016c"),
"Suffix" => Some("catalog-suffix-885db975a3"),
"TCOUNT increment <{increment}>:" => Some("catalog-tcount-increment-increment-79f9ab6108"),