Skip to content

21 ‐ How to update components

Jump to bottom
Pierre-Yves Lapersonne edited this page Dec 17, 2024 · 2 revisions

Before all, if you plan to add new components, contact the design team before so as to make them able to update their Figma kit then produce the evolutions in the JSON for the tokenator. Any improvement you bring without prior modifications by the design team can be lost in the next generation of tokens.

Create an issue

We need to trace any modifications, that is the reason why we need issues. You should use the dedicated issue template.

Submit a clean pull request

You may have to update several parts of the library to have a good implementation of the components. Please, refer to CONTRIBUTING and DEVELOP.

Things to not forget

Maintain tests

  • Update if nedded the UI and unit tests (to test rendering of components, tokens, etc.)
  • Ensure every UI tests work and pass
  • Ensure every unit tests work and pass

Maintain the documentation

  • Check the documentation of the Swift files is enough (Xcode preview, minimap MARK, comments, code samples, etc)
  • Check the DocC catalogs are updated (code samples, how to use the components, etc).
  • Update the CHANGELOG

No warnings

  • Check the SwiftLint does not through warnings nor errors
  • Build locally using Xcode the documentation and check if some warnings appear

Build alpha version or check locally

If needed, build an alpha release using the CI/CD pipeline job, or at least build locally the app with the update tokens and check modifications.

Merge with a nice commit

Finaly, merge the things into develop with the squash and merge commit mode, using conventional commit messages rules. If you bring breaking changes (i.e. remove or rename tokens, components or properties, thus breaking public API and retrocompatiblity), use the ! symbol. You should prefer refactor keyword if component is refactored, or feat if new component is added. If the changes are very small, maybe chore is enough, it is up to you and the code reviewers to define.

For example, for an update of component "OUDSButton" with internal changes, for issue number "abc" and pull request number "def":

refactor: improve `OUDSButton` component (#abc) (#def)

Add details on the commit body about the changes

But if you break public API of the components:

refactor!: improve `OUDSButton` component (#abc) (#def)

Add details in the commit body about non-breaking changes

BREAKING CHANGE: Add details in commit body about the breaking changes

And if the component is new:

feat: add `OUDSButton` component (#abc) (#def)

Add details in the commit body about changes
Clone this wiki locally