runem / lit-analyzer

Monorepository for tools that analyze lit-html templates
MIT License
317 stars 36 forks source link

Elements registered using `@customElement` decorator no longer get picked up by lit-analyzer #287

Closed MaKleSoft closed 1 year ago

MaKleSoft commented 1 year ago

Looks like using the @customElement() decorator is no longer sufficient for a custom element to be recognised by lit-analyzer. For a long time it was working but for a while now (a couple of weeks/months?) I've been getting no-unknown-tag-name warnings and go-to-definition, property type checking etc. is no longer working. I though it was some configuration issue with my project but someone just pointed out to me that adding the @customElement jsdoc tag fixes the problem.

In other words this works

/**
 * @customElement my-element
 */
export class MyElement extends LitElement {}

but this doesn't

@customElement("my-element")
export class MyElement extends LitElement {}

Is this a regression or intentional? Having both seems kind of redundant and I'd rather avoid adding the jsdoc tag to our many existing custom elements.

Thanks for maintaining this project btw! lit-plugin is by far my favourite VSCode extension and has boosted my productivity immensely!

Versions:

lit-plugin: v1.2.4 lit: v2.4.0 VSCode: v1.73.1

nickpelone commented 1 year ago

Wanting to add a 'me too' here. I noticed recently when I resumed a frontend project I work on that no-unknown-tag-name was firing on several of my components' tags.

At first I thought it was something weird I was doing to define some of them (generated from a factory-function kinda deal), but just bare normal ones that are exported and decorated with @customElement() are not being detected either. Like the OP said, this definitely used to work, but I'm not familiar enough with the codebase here to start to bisect when it happened (but probably will try here at some point).

Thanks for your time - this is an incredibly useful plugin!

tristanstcyr commented 1 year ago

This broke with Typescript 4.8. Downgrade to 4.7.x and it'll work again.

The issue has been fixed recently in web-component-analyzer: https://github.com/runem/web-component-analyzer/pull/249. lit-analyzer will need to depend on the updated version for this to be fixed.

MaKleSoft commented 1 year ago

This broke with Typescript 4.8. Downgrade to 4.7.x and it'll work again.

I'm on Typescript 4.7.4 (never upgraded to 4.8) and still experiencing this issue.

tristanstcyr commented 1 year ago

@MaKleSoft then maybe you're running into a different issue.

I found the root cause on my end when debugging web-component-analyzer by inserting console.log statements in the discoverDefinitions functions in ./node_modules/web-component-analyzer/lib/cjs/chunk-transform-analyzer-result-f3aa5495.js. It turned out that node.decorators was always undefined.

IcyFoxe commented 1 year ago

We have the same issue in our project. Fixing this would be a great help, because currently we are stuck without intellisense, and reworking every component to use customElements.define() instead would take a lot of time..

rictic commented 1 year ago

This should be fixed, install the @next tag