feat: Action Graph Optimization - Reduce Build Steps

[avrabe]

Summary

Optimize the build action graph to reduce the number of Bazel actions per component, resulting in faster builds.

Current State

Typical rust_wasm_component build has 5-6 actions:

1. Generate WIT bindings (wit-bindgen)
2. Compile to WASM (rustc via rules_rust)
3. Embed WIT in WASM (wasm-tools component embed)
4. Create component (wasm-tools component new)
5. Validate component (wasm-tools validate) - optional
6. Apply wizer (wizer) - optional

Each action has overhead: process spawn, file I/O, Bazel action cache checks.

Proposed Optimizations

A) Merge Embed + New

wasm-tools component new can take WIT directly, eliminating the intermediate embed step.

# Current: 2 actions
wasm-tools component embed --wit wit/ module.wasm -o embedded.wasm
wasm-tools component new embedded.wasm -o component.wasm

# Proposed: 1 action  
wasm-tools component new --wit wit/ module.wasm -o component.wasm

B) Integrate Validation

Run validation as part of component creation instead of separate action.

# Add --validate flag or check exit code
wasm-tools component new --wit wit/ module.wasm -o component.wasm && wasm-tools validate component.wasm

C) Skip Validation in Dev Mode

Add skip_validation = True option for faster development iteration.

D) Parallel Binding Generation

Use Bazel aspects to generate bindings for multiple components in parallel rather than sequentially.

E) Batch Operations (Future)

For projects with many components, batch multiple wasm-tools invocations:

wasm-tools component new --batch input1.wasm input2.wasm ...

Amortizes process startup cost.

F) Incremental WIT Processing

Cache parsed WIT representation; only regenerate bindings when WIT changes (not on every source change).

Expected Impact

Optimization	Actions Saved	Effort
Merge embed+new	1 per component	Low
Integrate validation	1 per component	Low
Skip validation (dev)	1 per component	Low
Parallel bindings	N/A (parallelism)	Medium
Batch operations	Varies	High

Total: 5-6 actions → 2-3 actions = ~50% faster builds

Benefits

• Faster builds (fewer process spawns)
• Better cache utilization
• Simpler action graph debugging
• Reduced disk I/O (fewer intermediate files)

New Features Enabled

• "Fast mode" for development builds
• Incremental component rebuilds
• Build time analytics

Impact

• Effort: Medium
• Risk: Low
• Value: Medium

Related

• Complements: Meta-Toolchain (feat: Meta-Toolchain - Consolidated WASM Tool Binary #250) - fewer tools = fewer actions

[avrabe]

⏸️ Status: Deferred - Phase 2 optimization

Action graph optimization is not critical at this time. The current build performance is acceptable for typical use cases.

Will revisit after the unified API work (which is currently blocked on WIT validation tooling). The optimization work would benefit from having a cleaner API surface to optimize against.

Tracked in strategic plan.