Architecture Decision Records
Architecture Decision Records (ADRs) document significant design choices made during the development of Web Engine Dev. Each record captures the context, decision, alternatives considered, and consequences.
ADR Index
| # | Title | Status | Summary |
|---|---|---|---|
| 001 | Archetype-Based ECS Storage | Accepted | Chose archetype-based storage over sparse sets for cache-friendly iteration and parallel-friendly processing |
| 002 | Dual ESM/CJS Publishing | Accepted | All packages publish as dual ESM + CJS using tsup with conditional exports for universal compatibility |
| 003 | WebGPU Rendering Strategy | Accepted | WebGPU-first strategy with WebGPU-only runtime execution |
| 004 | Third-Party Facade Pattern | Accepted | Use Rapier for physics via facade pattern; build custom pathfinding, audio, and netcode for ECS integration |
| 005 | Collision Detection Strategy | Accepted | Removed standalone collision package in favor of Rapier's integrated collision detection |
| 006 | Editor Architecture | Accepted | SolidJS UI, hexagonal architecture, ECS bridge read-only pattern, four-store rule |
| 007 | Data-Oriented Design | Accepted | DOD as the core architectural principle: SoA storage, systems as data transforms, ECS as single source of truth |
ADR Format
Each ADR follows a consistent structure:
- Status --
Proposed,Accepted,Deprecated, orSuperseded - Context -- What problem or question motivated this decision
- Decision -- What was decided and why
- Alternatives Considered -- Other approaches that were evaluated and why they were rejected
- Consequences -- Positive and negative impacts of the decision