Conventions and Guidelines
JavaScript Coding Guidelines​
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.
Testing​
Integration testing is based on Webdriver.io. You can run all tests using npm run test
.
If reasonable, take the time and write a test for the proposed change or fix. Learn more about testing at the Testing UI5 Web Components page.
Git Guidelines​
We adhere to the Conventional Commits specification.
The commit message consists of three parts:
- header
- body (optional)
- footer (optional)
Commit Header​
The commit header is the first line of the commit message. It consists of three parts: type, scope and description.
Commit Type​
- It must be one of the following:
fix
- a bug fix (note: this will indicate a release). If possible, include a test in your change.feat
- a new feature (note: this will indicate a release)docs
- changes to the documentation or samplesstyle
- changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)refactor
- 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
Commit Scope (optional)​
- It points to a specific component which is affected by the change. For example, ui5-button, ui5-card and ui5-table.
Commit Description​
- 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.
Commit Body (optional)​
After the commit header, there should be an empty line followed by the optional commit body.
- Describe the intention and reasoning of the change.
Commit Footer (optional)​
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
)
Example:
fix(ui5-button): correct focus with 'tab' key
The button should receive a correct focus outline
when the 'tab' key is pressed.
Fixes #42