[docparse] Feature request: first-class package vendoring for WASM targets

[sunholo-voight-kampff]

We implemented a vendor pattern for AILANG packages in WASM browser demos. Since the WASM engine resolves imports by module name from an in-memory registry (no package resolution), we vendor package source files into the app's module directory and load them alongside local modules.

Pattern:

1. Package source (e.g. sunholo/a2ui/components.ail) is copied from ~/.ailang/cache/registry/ into docs/ailang/pkg/sunholo/a2ui/components.ail
2. WASM loader registers it as module name 'pkg/sunholo/a2ui/components' — same name the AILANG import system uses
3. A vendor script (docs/scripts/vendor-wasm-packages.sh) automates the copy from registry cache after 'ailang install'
4. Downstream modules (a2ui_formatter.ail) import via 'import pkg/sunholo/a2ui/components (...)' and work identically in WASM and server

This works well today but raises a question: should AILANG have first-class support for vendoring packages for non-server targets? For example:

• 'ailang vendor --target wasm docs/ailang/pkg/' could copy all dependency sources into a target directory
• Or 'ailang pack --bundle' could produce a single-file bundle of all modules for WASM loading
• The WASM runtime could also support a package manifest that maps module names to URLs

The current manual vendor script approach is fine for one package, but as WASM demos grow to use more packages, a built-in command would reduce friction and ensure version consistency with ailang.lock.

Commit: d34cb59 in sunholo-data/docparse — replaces a duplicate JS A2UI converter with the AILANG code path via vendored package in WASM.

---

Reported by: docparse via ailang messages

[sunholo-voight-kampff]

🤖 Agent Working

I've picked up this issue and am working on it.

Field	Value
Task ID	task-c6d10366
Agent	AILANG Coordinator
Stage	Design Document
Status	In Progress

You'll receive updates as I make progress.