irgen prioritizes determinism, clear boundaries, and predictable output. Contributors must keep emitters dumb and place logic in the correct layer.
Design Constraints
Determinism is non-negotiable. Build-time decisions are preferred and runtime behavior must remain optional and non-authoritative.
Emitter Discipline
Emitters only read TargetIR and write files. They must never read policy, infer intent, or decide features.
Explicit Non-Goals
irgen is not a framework, not a runtime platform, and not a template engine. It generates projects that use existing frameworks.
Trade-Offs
irgen avoids SSR runtime and implicit behavior to keep output deterministic and easy to audit. SSG provides most benefits with fewer costs.
Contributor Checklist
Is this intent, constraint, or execution? Does it belong in DSL, policy, lowering, or emitter? Can it be decided deterministically?
Common Pitfalls
Avoid overloading the DSL or letting target concerns leak upward. Explicit beats clever.
Why irgen Exists
irgen favors clarity over magic, structure over templates, and decisions over guesses. It is built for developers who think in systems.