feat (labs/analyzer): support custom element analysis #3621
Conversation
This separates the current lit-element analysis into two layers: * custom elements * lit Primarily this is so we can detect non-lit elements we may depend on inside a lit project, giving the user full coverage of all the elements they're consuming.
🦋 Changeset detectedLatest commit: b239042 The changes in this PR will be included in the next version bump. This PR includes changesets to release 7 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
| events: Map<string, Event>; | ||
| slots: Map<string, NamedDescribed>; | ||
| cssProperties: Map<string, NamedDescribed>; | ||
| cssParts: Map<string, NamedDescribed>; | ||
| } | ||
|
|
||
| export class LitElementDeclaration extends ClassDeclaration { | ||
| interface LitElementDeclarationInit extends CustomElementDeclarationInit { | ||
| reactiveProperties: Map<string, ReactiveProperty>; |
There was a problem hiding this comment.
We'll do this in a separate PR, but I want to figure out how to reconcile reactiveProperties here with ClassField... Feels like one should just be a subtype of the other (or just a CustomElementClassField).
|
I'm looking into the CI failures... |
Yeah, it would be nice to refactor the tests a bit to dedupe them down, but we can handle that separately. For now I just aligned the (mostly duplicate) vanilla tests to the JSDoc-related changes I made at the end of my last PR. |
This separates the current lit-element analysis into two layers:
Primarily this is so we can detect non-lit elements we may depend on inside a lit project, giving the user full coverage of all the elements they're consuming.
@kevinpschaaf i had to do a lot of conflict resolution when getting this based onto master. so in the end i just made a new branch and cherry picked it out
if you could re-review to be sure all looks good still, that'd be appreciated
we also still need to figure out how to properly test this... roughly the same tests could be run against both lit and vanilla in theory. for now its the existing tests mostly, but maybe another pr can improve that