-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
custom elements manifest #219
base: master
Are you sure you want to change the base?
Conversation
Any update for this? cc @justinfagnani @kevinpschaaf |
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 |
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, |
context: TransformerContext | ||
): IterableIterator<schema.CssCustomProperty> { | ||
for (const cssProperty of declaration.cssProperties) { | ||
// TODO (43081j): somehow populate the syntax property |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
doubt we have logic to do this already. the old implementation passed a typescript type here, but of course css props don't have those. i suppose we'd need new logic to determine the right syntax, if thats even possible?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks James!
The big thing needed here is tests to see the output for various elements...
export function getPackageName(sourceFile: SourceFile): string | undefined { | ||
// TODO: Make it possible to access the ModuleResolutionHost | ||
// in order to resolve the package using "resolveModuleNames" | ||
// The following approach is very, very naive and is only temporary. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah... this needs to be fixed before this is merged I think.
@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:
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 i also agree we need a good set of tests here, ill try take a look when i can |
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 |
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