feat: WIT-Centric Build Model - Unified wasm_component Rule

[avrabe]

Summary

Redesign component rules around a WIT-first model with a single unified wasm_component rule instead of separate per-language rules.

Current State

4 separate rules with duplicated logic:

rust_wasm_component(wit=..., srcs=...)
cpp_component(wit=..., srcs=...)
go_wasm_component(wit=..., srcs=...)
js_component(wit=..., srcs=...)

Each rule duplicates:

• WIT handling (~200 lines)
• Binding generation logic
• Component creation steps
• Profile management

Proposed Solution

Single unified rule following the Component Model's WIT-first design:

wasm_component(
    name = "my_component",
    wit = ":interface.wit",
    world = "my-world",
    
    # Pick ONE implementation (mutually exclusive)
    rust = ":rust_lib",      # rust_library target
    # OR
    cpp = ":cpp_lib",        # cc_library target  
    # OR
    go = ":go_pkg",          # go_library target
    # OR
    js = ":js_sources",      # filegroup of JS sources
    
    # Common options work for all languages
    wizer = True,
    optimize = "release",
)

Implementation

1. Single wasm_component rule that:

   • Accepts WIT definition
   • Detects which language impl is provided
   • Generates appropriate bindings
   • Compiles using language-specific toolchain
   • Creates component with wasm-tools

2. Keep language-specific rules as aliases for backwards compatibility

Benefits

• Single mental model: "WIT + implementation = component"
• ~60% less code in rules (remove duplication)
• Consistent API regardless of language
• Easier to add new languages (just add impl attribute)
• Forces clean separation of interface and implementation

New Features Enabled

• Multi-language components (some exports in Rust, some in Go) - future
• Interface-driven testing (mock implementations)
• Automatic binding regeneration when WIT changes
• Component templates from WIT alone

Impact

• Effort: High
• Risk: High (API change)
• Value: Very High

Migration Path

1. Implement new wasm_component rule
2. Keep existing rules as aliases/wrappers
3. Deprecation warnings on old rules
4. Remove old rules in major version bump

Related

• Simplifies all future language additions
• Foundation for advanced composition features

[avrabe]

⏸️ Status: Deferred

The WIT-centric build model is blocked on standalone WIT validation tooling.

Reason for deferral:

• Import/export validation is incomplete (WasmComponentInfo.imports and WasmComponentInfo.exports fields are empty - TODOs in code)
• SDK→WASI version enforcement is documented but not enforced at build time
• No semantic WIT comparison (current validation uses grep-based string matching)
• Proper WIT validation requires parsing and semantic analysis - this should be a standalone tool

Prerequisite: A standalone WIT validation tool that can:

• Parse WIT files semantically
• Compare expected vs actual imports/exports
• Enforce SDK→WASI version compatibility
• Provide clear error messages for mismatches

Will revisit once the tooling gap is addressed. Tracked in strategic plan.