🏗️ Architecture: How should Platform Elements separate editing code from prod...

Date: 2026-03-25
Time: 21:47:29 UTC
Session: gspace1-270.4
Agent: storage
Confidence: 96%
Status: ✅ Documented

📋 Decision Context

Question:

How should Platform Elements separate editing code from production runtime?

Task: S270 Platform Elements Evolution

🎯 Decision Made

Chosen:

Two-bundle split via separate entry points: runtime.ts (production, 49.8KB gzip) and editor.ts (editor, 51.1KB gzip). Editor re-exports runtime + inspector + mutation system. Build script accepts --mode=production|editor flag. PeCompilationStrategy in Studio loads platform-editor.js; published platforms load platform-runtime.js.

Options Considered:

1. Runtime state flag (if editing mode) — still ships all code
2. Dynamic import() for editor modules — adds async complexity
3. Two entry points with build-time separation (chosen) — cleanest, zero runtime cost

💭 Reasoning

The previous monolithic bundle (179KB) always included inspector code (~5KB) even in production. A runtime state flag (if editing then...) would add complexity and still ship the code. The two-entry-point approach is a build-time separation — no runtime overhead, no conditional logic, and esbuild tree-shaking handles the rest. The architectural seam ensures future editing features (mutation receiver, undo/redo, error display) never leak into production. Verified: production bundle has 0 occurrences of ElementInspector, MutationExecutor, installMutationReceiver. Editor bundle has all of them.

📁 Files Involved

• libs/libs-structural/platform-elements/src/lib/runtime.ts
• libs/libs-structural/platform-elements/src/lib/editor.ts
• tools/scripts/build/bundle-platform-elements.ts
• libs/libs-structural/platform-preview/src/lib/strategies/pe-compilation.strategy.ts

🔗 Related

• Decision ID: dev_1774475249108_26umys7
• Session: 270
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation