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

Create package / custom element manifest validator page #3

Open
@justinfagnani

Description

@justinfagnani

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions