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
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:
customElements
fieldcustomElements
existsdescription
field.readme
field: the file exists, and is markdownjs
orcustom-element-definition
)declaration
fully resolves to a valid declarationdeclaration
points outside the package (until have cross-package references)custom-element-definition
export:name
is defined and contains a-
kind: "class"
withcustomElement: true
js
export:name
isdefault
,*
, or a valid identifierclass
:superclass
reference resolvesmixins
references resolvefield
:type
validates'function'
:'mixin'
:'variable'
: