Skip to content
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

Open
wants to merge 13 commits into
base: master
Choose a base branch
from
Open

custom elements manifest #219

wants to merge 13 commits into from

Conversation

43081j
Copy link
Contributor

@43081j 43081j commented Jun 5, 2021

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
Copy link

Any update for this? cc @justinfagnani @kevinpschaaf

@43081j
Copy link
Contributor Author

43081j commented Jun 27, 2021

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
Copy link
Contributor Author

43081j commented Jul 3, 2021

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

context: TransformerContext
): IterableIterator<schema.CssCustomProperty> {
for (const cssProperty of declaration.cssProperties) {
// TODO (43081j): somehow populate the syntax property
Copy link
Contributor Author

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?

@43081j 43081j changed the title WIP: custom elements manifest custom elements manifest Jul 3, 2021
@43081j 43081j marked this pull request as ready for review July 3, 2021 13:29
Copy link
Collaborator

@justinfagnani justinfagnani left a 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.
Copy link
Collaborator

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.

src/transformers/custom-elements-manifest/utils.ts Outdated Show resolved Hide resolved
src/transformers/custom-elements-manifest/utils.ts Outdated Show resolved Hide resolved
src/transformers/custom-elements-manifest/utils.ts Outdated Show resolved Hide resolved
@43081j
Copy link
Contributor Author

43081j commented Jul 19, 2021

@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
Copy link
Contributor Author

43081j commented Nov 6, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants