The Origami component specification is now deprecated. How Origami components are built is under active development and may change as Origami tooling and services are updated too. This is a non-normative reference for contributing to or creating new components.
Origami components contain an origami.json file at the top of the
component’s directory structure, with the type property set to "component". The origami.json manifest documentation covers the contents of this file.
A component’s name is used in the package.json, URLs, and CSS class names, so they:
Contain only ASCII letters, numbers and hyphens
Begin with a letter
Origami components are installable with the npm package manager.
As well as following the
package.json specification, components also include a:
"sass" property set to the component’s main Sass
entry-point if the component has Sass.
"description" property set to a short description of the
"keywords" property in order to help users discover the right
"type" property set to "module".
"license" property set to the SPDX license identifier for the
license of the component, e.g. “MIT”.
List any production Sass or Origami component dependencies under
"peerDependencies", to avoid using multiple versions of the same dependency.
"bugs" field as described in the package.json specification.
A component should have a README.md file at its root.
When a new major version of a component is released a migration guide should be written to help users upgrade from the previous release. The migration guide
is added to a MIGRATION.md file in the root of the component’s codebase,
and is linked to from the component’s README.md.
A component’s markup should be contained in a root element that:
Has a data-o-component attribute with value of the component’s name, or
Is defined as a
All data attributes and IDs are namespaced with the component’s name.
We recommend components only modify:
The component’s root element, and its children
Elements with any other data attribute in the component’s namespace,
and their children
Components are configurable using data attributes
Events triggered by a component should be namespaced under the
target component’s name