Skip to content

Add WASM module registry and admin panel extensibility via manifest convention#253

Closed
zyrakq wants to merge 2 commits into
trailbaseio:mainfrom
zyrakq:feature/wasm-modules-page-in-admin-panel
Closed

Add WASM module registry and admin panel extensibility via manifest convention#253
zyrakq wants to merge 2 commits into
trailbaseio:mainfrom
zyrakq:feature/wasm-modules-page-in-admin-panel

Conversation

@zyrakq

@zyrakq zyrakq commented Jun 24, 2026

Copy link
Copy Markdown
Contributor

Closes #252.

What this adds:

  • GET /_/admin/wasm-modules — new API endpoint listing all loaded modules with their metadata
  • WASM Modules page in the admin at /wasm-modules — shows each module with icon, display name, and description
  • Optional manifest convention — a module responds at /_/wasm/<file-stem>/manifest with a JSON object: display_name, icon, description, config_path. The path segment must match the file-stem of the .wasm file; a mismatch means the manifest is silently ignored. This makes the contract opt-in and collision-free
  • Module settings page at /wasm-modules/:name — when a module declares a config_path, the admin fetches it with admin credentials and injects the returned HTML fragment. Script tags are re-cloned so module JS initializes correctly
  • is_admin check added to wasm-runtime-guest — since this feature opens the door to admin-panel extensions, module endpoints that serve management UI must be able to guard access. The project didn't previously need this in the guest crate, but shipping admin-facing modules without a built-in auth check would push that burden onto every extension author individually

Style isolation:

The settings fragment is injected directly into the admin page DOM, so TrailBase's own styles will bleed into it. Extension authors should wrap their settings UI in a Web Component using Shadow DOM to get full style isolation. This is the recommended approach for any config_path implementation.

Real-world example:

To verify the manifest convention end-to-end, wcauth-tb-component can be used as a test module — it already implements the manifest endpoint and exposes a settings page. Build it from source, place the resulting binary as wcauth.wasm in traildepot, and it should appear in the WASM Modules page with its manifest applied.

Compatibility:

Non-breaking. Modules without a manifest endpoint continue to work exactly as before and appear in the list using their file-stem as the display name.

@zyrakq
zyrakq force-pushed the feature/wasm-modules-page-in-admin-panel branch from 261bea4 to 968d77f Compare July 4, 2026 02:05
zyrakq added 2 commits July 18, 2026 09:06
Made loaded WASM modules visible to administrators
Allowed modules to present a branded identity in the dashboard
Enabled modules to surface their own configuration UI in admin
Equipped module authors with built-in admin access control

Turn WASM into a first-class extension model for the admin
Remove the need for a separate admin interface per extension
Spare module authors from re-implementing admin access control
Introduced tb-html-fragment custom element that attaches a shadow
root and injects fragment HTML inside it, replacing direct innerHTML
assignment into a light-DOM container.

Prevents WASM component settings pages from leaking styles/markup
into or colliding with the admin app's own DOM and CSS, enforcing
isolation at the injection point rather than relying on convention.
@zyrakq
zyrakq force-pushed the feature/wasm-modules-page-in-admin-panel branch from 968d77f to c04af71 Compare July 18, 2026 12:31
@zyrakq zyrakq closed this Jul 18, 2026
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.

Allow WASM modules to extend the TrailBase admin panel

1 participant