We enforce code style rules using ESLint. Execute npm run lint
to check your code for style issues.
You may also find an ESLint integration for your favorite IDE here.
Integration testing is based on Webdriver.io. You can run all tests using npm run test
.
We adhere to the Conventional Commits specification.
The commit message consists of three parts:
- header
- body (optional)
- footer (optional)
The commit header is the first line of the commit message. It consists of three parts: type, scope and description.
- It must be one of the following:
fix
- a bug fix (note: this will indicate a release)feat
- a new feature (note: this will indicate a release)docs
- documentation only changesstyle
- changes that do not affect the meaning of the coderefactor
- a code change that neither fixes a bug nor adds a featureperf
- a code change that improves performancetest
- adding missing testschore
- changes to the build process or auxiliary tools and libraries such as documentation generationrevert
- revert to a commitWIP
- work in progress
- It points to a specific component which is affected by the change. For example, ui5-button, ui5-card and ui5-table.
- Use the imperative present tense. Instead of "I added feature xy" or "Adding tests for" use "Add feature xy" or "Add tests for".
- It should be no more than 100 characters long.
After the commit header, there should be an empty line followed by the optional commit body.
- Describe the intention and reasoning of the change.
After the optional commit body, there should be an empty line followed by the optional footer.
- If the change introduces a breaking change, it should start with BREAKING CHANGE: followed by a description of the change.
BREAKING CHANGE: remove press event
- If the change fixes an issue reported on GitHub, add the following line to the commit message:
Fixes #<issueNumber>
(e.g.Fixes #42
)
fix(ui5-button): correct focus with 'tab' key
The button should receive a correct focus outline
when the 'tab' key is pressed.
Fixes #42