web-component-analyzer icon indicating copy to clipboard operation
web-component-analyzer copied to clipboard

Published 20 hours ago • verified publisher icon runem

custom elements manifest

Open 43081j opened this issue 3 years ago • 5 comments

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

43081j avatar Jun 05 '21 12:06 43081j

Any update for this? cc @justinfagnani @kevinpschaaf

herberthobregon avatar Jun 27 '21 17:06 herberthobregon

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 avatar Jun 27 '21 18:06 43081j

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 avatar Jul 03 '21 11:07 43081j

@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 avatar Jul 19 '21 21:07 43081j

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

43081j avatar Nov 06 '21 14:11 43081j