Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Can tag names be TypeScript variables? #278

Open
driesva opened this issue Nov 9, 2023 · 2 comments · May be fixed by #279
Open

Can tag names be TypeScript variables? #278

driesva opened this issue Nov 9, 2023 · 2 comments · May be fixed by #279

Comments

@driesva
Copy link

driesva commented Nov 9, 2023

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
Copy link
Author

driesva commented Nov 22, 2023

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
Copy link
Author

driesva commented Nov 24, 2023

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.

@driesva driesva linked a pull request Nov 24, 2023 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat: support tag names which are static class properties driesva/web-component-analyzer
1 participant
@driesva