Attributes fail on components whose conditional Element type is instantiated with an unresolved generic #14

Activity

1. NullVoxPopuli

   added a commit that references this issue on Aug 27, 2026

   Document the Node 22 launcher failure and the known upstream differences

   ...

   c4259a3
2. NullVoxPopuli-ai-agent commented on Aug 27, 2026

   

   NullVoxPopuli-ai-agent

   on Aug 27, 2026

   Contributor

   More actions

   This is not a TypeScript 7 difference. TypeScript 5.9 on the transformed text reports the same error. ember-tsc hides it: the diagnostic anchors on generated text that no Volar verification mapping covers, and Volar drops diagnostics it cannot map back. Glint's template-to-typescript.ts describes this gap in its wideVerification comments. The mapper maps every synthesized region back to the template construct that produced it, so the error shows.

   The types that reject the code live in @glint/template:

   • ComponentLike<{ Args: Record<string, never> }> degrades to never-args when invoked through a block-param path #13: Record<string, never> has an index signature, so ComponentSignatureArgs in -private/signature.d.ts takes the { Named; Positional } branch and both resolve to never. Direct looks clean only because a lowercase <one /> is an element, not a component.
   • Attributes fail on components whose conditional Element type is instantiated with an unresolved generic #14: a conditional Element over an unresolved type parameter never resolves, so Partial<...> accepts no attribute.
   • Curried component ({{component X a=1}}) in content position is not accepted as ContentValue #15: {{component Comp a="hi"}} yields a curried Invokable, and ContentValue accepts only ComponentReturn<{}, any>.

   #24 records each in test/diagnostics-tests/upstream-differences/ so a change on either side shows up. The mapper keeps reporting them: dropping diagnostics on synthesized text would also hide real errors such as a missing required argument. Next step is a Glint report, after a check against the current Glint release.
3. NullVoxPopuli commented on Aug 27, 2026

   

   NullVoxPopuli

   on Aug 27, 2026

   OwnerAuthor

   More actions

   Note

   This investigation was done with Claude (via Claude Code) — apologies in advance if it missed something; corrections welcome.

   Like #13, this reproduces standalone under both TS 6.0.3 and TS 7.1 nightly when the transformed output is checked directly (with ember-source/types + @glint/ember-tsc/types referenced) — so it's not a mapper or TS 7 divergence, it's inherent to how glint's attribute checking interacts with generic-dependent Element types.

   Mechanism

   Luna's Button declares (property-level generics, both defaulted):

   interface LunaButtonSignature<Href extends string | undefined = undefined, AsDiv extends boolean | undefined = undefined> {
     Element: AsDiv extends true ? HTMLDivElement : Href extends string ? HTMLAnchorElement : HTMLButtonElement;
     // ...
   }

   When a generic wrapper component threads its own unresolved type parameter into @href/@shouldRenderAsDiv:

   export default class Outer<Href extends string | undefined = undefined> extends Component<OuterSignature<Href>> {
     <template>
       <Button @href={{@href}} data-x="1">hi</Button>
     </template>
   }

   Href stays unresolved inside Outer's body, so Button's Element is a deferred conditional type. The transform emits:

   __glintDSL__.applyAttributes(__glintY__.element, { "data-x": "1" });

   and applyAttributes<T extends Element>(element: T, attrs: Partial<AttributesForElement<T>>) — where AttributesForElement<T> is itself a chain of conditionals over T — can never evaluate, so every attribute (even universally-valid data-*) fails:

   error TS2353: Object literal may only specify known properties, and '"data-x"' does not exist in type
   'Partial<((Href extends string ? HTMLAnchorElement : HTMLButtonElement) extends null ? unknown : ...) extends HTMLElement ? ... : ...>'
   

   Identical output from both compilers. Defaults on the generics don't help — the deferral comes from the outer component's unresolved parameter, not from Button's own parameters lacking defaults.

   Options

   1. Consumer-side (recommended, what we'll do in optro-frontend): generic wrappers shouldn't thread unresolved type params into Element-selecting args. Passing a concrete string | undefined makes the conditional evaluate (to HTMLButtonElement — slightly imprecise when an href is present, but checkable).
   2. @glint/template-side: there's no type-level way to detect "deferred conditional" and fall back, short of weakening applyAttributes for everyone (e.g. attrs: Partial<AttributesForElement<T>> | DataAttributes). I don't think that trade is worth it, but noting it for completeness.

   Happy to close this as by-design once the guidance is written down somewhere (docs / known-issues).