Skip to content

fix(pack): resolve embedded fs directories from the module root#360

Open
skhaz wants to merge 1 commit into
mainfrom
fix/embed-fs-source-root
Open

fix(pack): resolve embedded fs directories from the module root#360
skhaz wants to merge 1 commit into
mainfrom
fix/embed-fs-source-root

Conversation

@skhaz

@skhaz skhaz commented Jun 17, 2026

Copy link
Copy Markdown
Member

Why

Packing or publishing a module that ships embedded filesystems — e.g. a UI bundle and a WASM binary — could report success while embedding zero files. The embed stage resolved each fs.directory path against the process working directory instead of the module source root the runtime uses, then skipped a missing directory with only a warning while still rewriting the entry to fs.embed. The result was a .wapp whose fs.embed entries had no backing resource; installed modules served no UI and failed to load the WASM binary.

What

  • New api/service/fs/directory.ResolveDirectory centralizes directory resolution (absolute / base: project / module source root); the runtime directory manager and the embed build stage now share it, so they cannot drift.
  • The embed stage resolves module-relative directories against the module root (the lock loader already registers per-module source roots; publish passes the module root explicitly) and now returns an error when an embeddable directory cannot be found, instead of silently producing a broken pack.

Proof (CLI, ui+wasm module)

Before — silent success, empty pack (working dir does not contain the asset dirs):

$ wippy pack --embed ui_fs,wasm_fs out.wapp
✓ Pack created successfully    Size: 0.87 KB    exit 0
# inspecting the pack:
RESOURCES: 0
  - id=app:ui_fs    kind=fs.embed      # claims an embedded fs
  - id=app:wasm_fs  kind=fs.embed      # claims an embedded fs
# 0.87 KB — the 14 KB WASM is absent

After — fails loudly, no broken pack:

$ wippy pack --embed ui_fs,wasm_fs out.wapp
✗ Error: stage 'embed_fs' failed: embed app:ui_fs: directory "./static" not found
exit 1

After — correct layout embeds both filesystems:

$ wippy pack --embed ui_fs,wasm_fs out.wapp
✓ Pack created successfully    Size: 7.60 KB
  Embedded resources:
    • app:ui_fs   (1 files, 0.03 KB)
    • app:wasm_fs (1 files, 14.07 KB)   # WASM actually embedded
# inspecting the pack:
RESOURCES: 2
  - id=app:ui_fs    type=tree files=1 size=28
  - id=app:wasm_fs  type=tree files=1 size=14410

Testing

  • New unit + integration tests (incl. an end-to-end stage→wapp.Writer→read-back that embeds and reads both the UI and WASM filesystems). Reverting each fix facet makes the matching test fail.
  • golangci-lint clean; go vet clean; full module build clean; full short race test suite green.
  • Mutation testing (gremlins): 100% on both changed packages.

Why: Packing or publishing a module that ships embedded filesystems
(e.g. a UI bundle and a WASM binary) could report success while embedding
zero files. The embed stage resolved each fs.directory path against the
process working directory instead of the module source root the runtime
uses, then skipped a missing directory with only a warning while still
rewriting the entry to fs.embed -- producing a pack whose fs.embed
entries had no backing resource. Installed modules then served no UI and
failed to load the WASM binary.

What: Centralize directory resolution in
api/service/fs/directory.ResolveDirectory (absolute / project base /
module source root) and reuse it from the runtime directory manager and
the embed build stage. The stage resolves module-relative directories
against the module root (the lock loader registers per-module source
roots; publish passes the module root explicitly) and now returns an
error when an embeddable directory cannot be found, instead of silently
shipping a broken pack.
@skhaz skhaz requested a review from wolfy-j June 17, 2026 15:54
@skhaz skhaz marked this pull request as draft June 17, 2026 16:49
@skhaz skhaz marked this pull request as ready for review June 17, 2026 17:43
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.

1 participant