Emitter Framework UX - Revisit supporting type-less components.

[joheredi]

Current Situation
Emitter Framework (EF) re-exports the Alloy components it builds on top of, allowing emitters to import an EF component even when they don’t need to pass a TypeSpec type. In practice, this means you can pick up a component from EF instead of importing it directly from Alloy.

Upsides

• Fewer imports to track (you don’t have to remember both @alloyjs/... and @typespec/emitter-framework/...).

Downsides

• Cognitive Load: It’s harder to know whether you should import the component from EF or from Alloy directly.
• Inconsistency Risk: There’s potential for subtle bugs if props from EF components don't end up flowing all the way down into Alloy components or do in unexpected ways.

---

Proposal

Remove support for “Type-less” (Alloy) components in EF so that the distinction is always clear:

• If you need to generate something from a TypeSpec Type, import the component from Emitter Framework (EF).
• If you don’t have a TypeSpec type, import the building block directly from Alloy.

Rationale

1. Emitters Already Import Both
   In practice, emitters frequently have to pull in building blocks from EF and Alloy anyway. The re-exports in EF rarely save enough friction to justify the confusion.
2. No Full Alloy Abstraction Goal for EFv2
   If we were aiming to completely hide Alloy behind EF, re-exports would make sense. But since EFv2 isn’t trying to become a one-stop shop for everything Alloy provides, keeping the re-exports only creates ambiguity.

---

By removing the “Type-less” exports from EF, we make it unambiguous which package to use in each situation, reduce the mental overhead of choosing between EF-vs-Alloy imports, and avoid accidental inconsistencies at runtime.

[bterlson]

I suppose I can see how what we have now is an awkward middle ground. Probably it makes sense to only support receiving a type prop and tell people to import from alloy when they just want to emit some syntax, or else re-export everything so in the 95% usecase you have only one place to look for imports. I remain not sure which approach is best.