You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 9, 2023. It is now read-only.
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:
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':