Rune Mehlsen

I haven't yet built functionality, so this PR is still relevant :-) Here are my initial thoughts about what needs to be done in order to support this rule: ###...

I just got a simple (and perhaps better) idea we could explore that's even easier to implement. We can implement a function in `ts-simple-type` or `web-component-analyzer` with the signature `getLibType(name:...

I just published `v1.1.1` of `web-component-analyzer` which includes support for event lib types as mentioned above. I went with the solution where event types are generated directly from lib declaration...

I just merged the `1.2.0` branch into `master`, so you can safely rebase this branch on `master` and choose that branch as the target of this PR.

@43081j Is it okay if I add some commits to this PR? I would love to get this awesome feature into a release :-)

Thanks! I'll take a stab at it now then :+1:

I've now improved type checking for events (also when we don't know the event type for a given event). In addition, `lib.dom.d.ts` is now scanned for global events and event...

Here's another point that we need to take into account. When collecting events, I merge events with the same name because events bubble (see picture). Therefore the type of "change"...

Thanks for the suggestion! I already have functionality in the CLI to analyze a glob/directory called `analyzeGlob`. This function creates a program and checker. https://github.com/runem/web-component-analyzer/blob/4f3b5ad4a9c26cb4270519d4153089914da3c1d1/src/cli/util/analyze-globs.ts#L33-L37 It's not aware any `tsconfig.json`...

This is an issue with the following line responsible for merging modifiers: https://github.com/runem/web-component-analyzer/blob/master/src/analyze/stages/merge/merge-util.ts#L37 Here's a short description of what happens and why I'm still considering what would be the expected...