fix(pack): resolve embedded fs directories from the module root#360
Open
skhaz wants to merge 1 commit into
Open
fix(pack): resolve embedded fs directories from the module root#360skhaz wants to merge 1 commit into
skhaz wants to merge 1 commit into
Conversation
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.directorypath 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 tofs.embed. The result was a.wappwhosefs.embedentries had no backing resource; installed modules served no UI and failed to load the WASM binary.What
api/service/fs/directory.ResolveDirectorycentralizes directory resolution (absolute /base: project/ module source root); the runtime directory manager and the embed build stage now share it, so they cannot drift.publishpasses 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):
After — fails loudly, no broken pack:
After — correct layout embeds both filesystems:
Testing
wapp.Writer→read-back that embeds and reads both the UI and WASM filesystems). Reverting each fix facet makes the matching test fail.golangci-lintclean;go vetclean; full module build clean; full short race test suite green.