Skip to content
This repository has been archived by the owner on Nov 9, 2023. It is now read-only.

Create package / custom element manifest validator page #3

Open
justinfagnani opened this issue Jul 29, 2022 · 1 comment
Open

Create package / custom element manifest validator page #3

justinfagnani opened this issue Jul 29, 2022 · 1 comment

Comments

@justinfagnani
Copy link
Contributor

To help package maintainers publish valid custom elements manifests, we should add a validator page.

This page will have an input for an npm package name. Entering a package name will trigger a standard import of the page into the registry, and report validation errors in the UI. This means that we will have to store validation errors in the database in order to show errors without performing a new import on already imported packages.

Validation checks can be categorized as those strictly required to process a CEM and those the registry add for inclusion criteria (package type module, etc).

Some validation checks:

  • ✅ package.json has customElements field
  • ✅ Manifest pointed to by customElements exists
  • ✳️ package.json has a description field.
  • ✅ Manifest parses as valid JSON
  • ✅ Manifest schemaVersion number is known
  • ✅ Manifest validates with the corresponding JSON schema for manifests of that version
  • ✳️ The manifest has a readme field: the file exists, and is markdown
    • ✳️ The file exists
    • ✳️ Parses as GitHub Flavored markdown
    • ✳️ Doesn't contain unsupported HTML elements
  • For every module listed in the manifest:
    • ✅ The module exists in the published package
    • ✳️ The module is in the package exports (Maybe? We don't differentiate between the exported and internal modules in CEM, but internal modules may need to be described because they have the original declarations)
    • ✳️ The module parses/validates as a module (strict mode, doesn't use CJS APIs)
    • For every export of the module
      • ✅ Type of export is known (js or custom-element-definition)
      • declaration fully resolves to a valid declaration
      • ✳️ Warn if declaration points outside the package (until have cross-package references)
      • ✳️ custom-element-definition export:
        • ✳️ name is defined and contains a -
        • ✳️ Resolved declaration is kind: "class" with customElement: true
      • ✳️ js export:
        • ✳️ name is default, *, or a valid identifier
    • For every declaration of the module:
      • class:
        • superclass reference resolves
        • mixins references resolve
        • ✅ ... all member's references resolve
          • field: type validates
      • 'function':
        • TODO
      • 'mixin':
        • TODO
      • 'variable':
      • TODO
@thepassle
Copy link

If a package has a package export map, the manifest should also be added there

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

No branches or pull requests

2 participants