Add type-system support for custom elements / web components

[NullVoxPopuli-ai-agent]

Resolves #808. Supersedes #1016 (rebuilt on current main, which has moved ~360 commits since that branch's base).

What this adds

Two global registries in @glint/template, both empty by default and populated by projects via declare global:

import '@glint/template';
import type { MyCustomElement } from './wherever';

declare global {
  interface GlintCustomElementTagNameMap {
    'my-custom-element': MyCustomElement;
  }

  interface GlintCustomElementAttributesMap {
    'my-custom-element': {
      'prop-num': number;
      'prop-str': string;
    };
  }
}

<my-custom-element prop-num={{123}} prop-str="hello"></my-custom-element>
{{! element is typed as MyCustomElement; attributes are checked }}

The registries are independent, and everything unregistered behaves exactly as it does today:

Registration	Element type	Attributes
element + attributes	registered type	strictly checked
element only	registered type (modifiers, ...attributes, hover)	anything accepted
attributes only	Element	strictly checked
neither (status quo)	Element	anything accepted

Augmenting the DOM's standard HTMLElementTagNameMap (the Lit convention) also works for the element-type half; GlintCustomElementTagNameMap exists for projects that prefer not to extend the DOM's own registry.

How it works

• emitElement(...) now returns { name, element, attributes } (previously just { element }), and ElementForTagName falls back to GlintCustomElementTagNameMap before Element.
• Plain elements resolve attributes by tag name: the transform emits a new applyTagAttributes(__glintY__, { ... }) DSL call whose attrs type comes from the new AttributesForTagName<Name>. This is what lets attributes-only registrations work — there's no element type to reverse-look-up.
• Components are untouched: they still emit applyAttributes(__glintY__.element, { ... }) and resolve attributes from the signature's Element type, so all existing elementless-component diagnostics/augmentations are byte-for-byte unchanged. AttributesForElement<T> additionally does a reverse lookup into the custom-element registry, so a component with Element: MyCustomElement gets the same attribute checking.
• AttributesForElement<T> also gains a graceful fallback: an HTMLElement/SVGElement subclass that isn't in any registry now accepts arbitrary attributes. Previously the type-name lookup produced never, which rejected every attribute (including class) for such elements.

Differences from #1016

#1016 was exploratory and internally inconsistent (it carried four different registry names across code/docs/fixtures, and a generated GlintTagNameAttributesMap whose duplicate HTML/SVG keys — a, script, style, title — can't compile). This PR keeps its core architecture (name-keyed registries, name/attributes on the emitElement result, tag-name-based attribute resolution) with these deliberate changes:

• Two clearly-named registries (GlintCustomElementTagNameMap, GlintCustomElementAttributesMap), both keyed by tag name; no generated tag-name map is needed, so bin/build-elements.mjs and elements.d.ts are untouched.
• Unregistered tags stay permissive (Record<string, AttrValue>), matching today's behavior, rather than being narrowed to global HTML attributes — no breaking change for existing users of custom elements.
• Components keep the applyAttributes(__glintY__.element, ...) emit instead of switching everything to applyAttributes(__glintY__, ...), which avoids the nested/uglier "An Element must be specified..." diagnostics that Add support for typed custom-elements and web-components #1016 had to counteract with message-text sniffing in the diagnostic augmentation layer.

Testing

• New type tests: packages/template/__tests__/custom-elements.test.ts (+ registry in a separate module, proving cross-file registration), private/ElementForTagName.test.ts, additions to attributes.test.ts / AttributesForElement.test.ts.
• New transform tests + an end-to-end fixture test-packages/ts-template-imports-app/src/custom-elements.gts with @glint-expect-error assertions (verified they're load-bearing: making a flagged line valid fails with "Unused '@ts-expect-error' directive").
• Full local run: all test:typecheck / test:tsc suites, package-test-core vitest (247 tests), ts-extensionless-app, v2-ts-ember-addon testem, VS Code TS-plugin smoke tests, and pnpm lint all pass.

🤖 Generated with Claude Code

[NullVoxPopuli-ai-agent]

Follow-up pushed: TypeScript's excess-property check only reports the first unknown key per object literal, so <my-custom-element foo="hi" bar="hi"> only flagged foo. Each attribute is now applied in its own applyTagAttributes/applyAttributes call, so every unknown attribute gets its own diagnostic. This also fixes the same latent first-error-only behavior for built-in elements and component attributes.

[NullVoxPopuli-ai-agent]

Also pushed: hovering an element's tag name now shows its element type, and go-to-definition resolves to its HTMLElementTagNameMap / GlintCustomElementTagNameMap registry entry — for built-ins too, which closes out the other half of #808's report (<a> showing no type info).

Implementation note: the transform emits two discarded elementTypes references per element — an identifier form (elementTypes.my_element, hyphens→underscores like the each-in → Globals.each_in keyword aliases) that serves hover, and a raw quoted-key form (elementTypes["my-element"]) that serves navigation. Hover needs the identifier because Volar drops quickinfo whose textSpan (quotes included) can't map back to the template; navigation needs the raw key because TypeScript keeps no declaration links through key-remapped mapped types. Each reference's Volar mapping is capability-scoped so they don't double-report. Covered by new language-server tests (element-tag-hover.test.ts).

[NullVoxPopuli-ai-agent]

Hover polish per feedback: tag-name hover now shows just the element type (MyCustomElement, HTMLDivElement) instead of the property-style (property) my_custom_element: MyCustomElement. Done in the tsserver plugin's getQuickInfoAtPosition proxy — when the hovered position maps to a plain element's tag name, the (property) name: prefix is stripped from the quickinfo displayParts. Components and all other hovers are untouched, and JSDoc on registry entries still comes through.

[NullVoxPopuli-ai-agent]

Attribute-name hover/goto fixed (was surfacing the private __glintY__ type): the applyTagAttributes/applyAttributes target-argument mapping onto the attribute node is now verification-only (it exists purely to anchor invalid-element diagnostics), so it no longer serves hover/navigation/completion. With that pollution gone, go-to-definition on an attribute resolves to its declaration (e.g. your GlintCustomElementAttributesMap entry) and hover shows (property) 'prop-num': number. Hyphenated names needed one extra piece: their quoted object keys get their quickinfo dropped by Volar (textSpan includes the quotes), so the tsserver plugin synthesizes the property quickinfo from the contextual type with a source-space span. Also generalized captureMapping so @glint-expect-error directive support applies to explicitly-provided code features. New tests cover attr hover + goto for both custom and built-in elements.

[NullVoxPopuli-ai-agent]

Fixed go-to-definition on <my-custom-element> in real editors (VS Code + Neovim reported broken): editors use tsserver's definitionAndBoundSpan command, not the plain definition command the earlier tests exercised — and Volar's definitionAndBoundSpan proxy drops the entire result when the origin ("bound") span can't translate back to the template (our quoted elementTypes[\"my-element\"] key includes quotes with no source counterpart). The tsserver plugin now falls back to getDefinitionAtPosition's definitions and synthesizes the bound span from the mapping tree (the tag/attribute name range). The definition tests were switched to definitionAndBoundSpan so they exercise the same path editors do.