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
'function':
'mixin':
'variable':- TODO
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:
customElementsfieldcustomElementsexistsdescriptionfield.readmefield: the file exists, and is markdownjsorcustom-element-definition)declarationfully resolves to a valid declarationdeclarationpoints outside the package (until have cross-package references)custom-element-definitionexport:nameis defined and contains a-kind: "class"withcustomElement: truejsexport:nameisdefault,*, or a valid identifierclass:superclassreference resolvesmixinsreferences resolvefield:typevalidates'function':'mixin':'variable':