Can tag names be TypeScript variables?

[driesva]

I had the idea to store the LitElement tag name as literal (as static member of the class) and refer to it in the decorator, HTMLElementTagNameMap, query selectors, ...
But it turns out web-component-analyzer (and as such lit-analyzer) is unable to retrieve the tag name value.

A basic example:

import type {TemplateResult} from 'lit';
import {html, LitElement} from 'lit';
import {customElement, property} from 'lit/decorators.js';

@customElement(FooBar.TAG)
export class FooBar extends LitElement {

  static readonly TAG = 'foo-bar';

  @property() baz = 'bazzz';

  override render(): TemplateResult {
    return html`${this.baz}`;
  }

}

declare global {
  interface HTMLElementTagNameMap {
    [FooBar.TAG]: FooBar;
    // 'foo-bar': FooBar; // works
  }
}

From application point of view, this seems to work correctly but analyzing gives:

Web Component Analyzer analyzing 1 file...
# TAG

## Properties

| Property | Attribute | Type     | Default |
|----------|-----------|----------|---------|
| `baz`    | `baz`     | `string` | "bazzz" |

Notice the TAGinstead of foo-bar.
Obviously lit-analyzer then complains about rule no-invalid-tag-name

Is this a limitation of the web-component-analyzer?
Or is this not possible in TypeScript at all?

[driesva]

After some debugging I found out myself that's a limitation of web-component-analyzer parsing logic in function resolveNodeValue

There's no support for nodes of type PropertyDeclaration.

I'll make a change and open a PR

[driesva]

I also found that lit-analyzer triggers no-missing-element-type-definition for such cases.

lit-analyzer uses function discoverDefinitions which calls getInterfaceKeys. If PropertyDeclaration is supported, it wil resolve the static class property found in HTMLElementTagNameMap. However that node is not directly part of the HTMLElementTagNameMap hierarchy which lit-analyzer relies on when evaluating that rule. As such lit-analyzer reports that the web component has not been registered...

I've found a workaround which I'll include in the PR, but maybe it needs a better solution.