custom elements manifest

runem / web-component-analyzer

CLI that analyzes web components and emits documentation

https://runem.github.io/web-component-analyzer

MIT License

507 stars 65 forks source link

custom elements manifest #219

Open 43081j opened 3 years ago

43081j commented 3 years ago

This is just a quick go at implementing the latest custom elements manifest in the analyzer.

There's discussion going on still around what tooling we use to generate manifests and where, but that shouldn't affect this implementation as we should still update WCA's to be current (it already has one, outdated though).

It is still WIP as we need to detect element declarations, not only exports.

cc @justinfagnani @kevinpschaaf

herberthobregon commented 3 years ago

Any update for this? cc @justinfagnani @kevinpschaaf

43081j commented 3 years ago

keep in mind i still need to add custom element declaration discovery into this, but it won't be difficult as we already have most of the logic.

it would be great to get this to a state where it is mergeable so people can start generating manifests against the latest spec

43081j commented 3 years ago

i've now updated it to also process element declarations, so this should be most or all of the 1.0 schema supported now.

i left a few TODOs around the code ill leave comments on for any reviewers who can help

have tested against lit-element-starter-ts and it seems to discover everything except the inferred return type for the render method.

anyone wants to try it, node cli.js analyze PATH_TO_STARTER_REPO --format custom-elements-manifest

43081j commented 3 years ago

@justinfagnani i've done some of the feedback, will try get to the rest this week some time

there's a couple of annoyances i've noticed which maybe we can do separate PRs to sort out:

formatting is inconsistent in the repo. i tried to add a prettierrc here to be more explicit, but running prettier now reformats most of the repo. indentation is mixed all over the place
the loose null checks bother me, if (foo != null) - we're in a strongly typed repo, we should be capable of knowing if its null or undefined we need to compare against rather than lazily checking like this

also custom-elements-manifest isn't working for me locally as a dependency. tsc doesn't seem to be able to infer where to find the types, maybe having a main as a JSON file isn't valid? maybe we need to set types explicitly?

i also agree we need a good set of tests here, ill try take a look when i can

43081j commented 3 years ago

sorry this went stale! i've rebased onto master and sorted a few of the PR comments.

i've also opened webcomponents/custom-elements-manifest#87 , we need that before we can merge.

i still need to figure out getPackageName too