The “Create A New Origami Component” tutorial is split into nine parts and is intended to be followed sequentially from start to finish:
In part nine we will learn how to publish our component to the Origami registry 🎉, and discuss the lifecycle of a published component.
We don’t actually want to publish an example component o-example. If you have been following along so far using o-example, rather than working on your own component that should actually be published, read this part of the tutorial as a reference only until you’re ready to publish a new component for real.
Origami components are stored in the Origami monorepo, under the components directory. We will start by committing the boilerplate as an initial commit. Our commit messages use a simplified form of conventional commits. Origami component’s release process is automated using commit messages to identify the next version number to release, so it’s important to use conventional commits.
[type]: [description]
[body]
The type can be any of feat, fix, docs or backstage.
The prefix is used to calculate the version number to release – according to semver – and the section of the release notes to place the commit message in.
| type | when to use | release level | release note section |
| --------- | ----------------------------------- | ------------- | -------------------- |
| feat | a feature has been added | `minor` | Feature |
| fix | a bug has been patched | `patch` | Bug fixes |
| docs | a change to documentation | none | Documentation |
| backstage | any changes that aren't user-facing | none | none |
Indicate a breaking change by placing an ! between the type name and the colon. We will use feat! to do an initial release.
git add --all
git commit -m 'feat!: create my o-example component'
git pushAfter pushing your commits you should be able to open a pull request. If you have never open a PR (pull request) you can read more about it in github documentation
To be able to opon a PR you will need to be part of origami collaborators team. If you are not a member already ask #origami-support to help you.
After the first release Origami components may be released automatically by using conventional commits. You will need to figure out what counts as a breaking change, and what counts as a feature or patch and use correct commit message.
We use semver specification for new releases. The semver specification documents what constitutes a major, minor, or patch release. There are also some Origami specific considerations to keep in mind when versioning a component. For example we may opt to release a major version of a component even with a compatible api if it includes drastic visual changes.
As other teams may depend on Origami components its important to follow the semver specification when versioning components as discussed previously. It is also important to communicate upcoming changes. The Origami specification includes a section on the component lifecycle which includes guidance on how to manage existing components as they mature. The guidance includes how to communicate new releases, the deprecation of component features, and the deprecation of components which are no longer needed.
If you have followed along this far congratulations!
We hope this step-by-step tutorial has helped make you feel more able to contribute to Origami. Both in terms of creating new components, maintaining existing components, and influencing the direction of Origami as a whole.
If you have any questions, bug reports, or feature requests please contact the Origami team . You can find the team on Slack in #origami-support.