Contributing

Contributions to the UI Kit are welcome — whether it’s fixing bugs, improving docs, suggesting components, or joining the discussion via GitHub or our community channels.

Submitting an Issue

Use our issue templates when filing issues.
Before submitting, search existing issues to check if your question or bug has already been addressed.

Bug Reports 🐛

If you encounter a bug, please open a bug report. Include as much detail as possible to help us reproduce the issue. Even better — feel free to submit a pull request with a fix.

Feature Requests ✨

To suggest a new feature or enhancement, open a feature request. Feature requests may include new components or improvements to existing ones.

Submitting a Pull Request

Be sure that an issue describes the problem you’re fixing, or documents the design for the feature you’d like to add. All contributions should target the master branch or a previous major version (eg. v4.x).
Maintainers will be responsible for reviewing and merging the Pull Request.

Setup

Pull the latest master branch.
Always work and submit pull requests from a branch:
```
git checkout -b YOUR_BRANCH_NAME master
```
Make sure you follow our coding standards, and add new test cases where appropriate following the testing guidelines.
Commit your changes using a descriptive commit message that follows our commit message guidelines.
Once ready for feedback from other contributors and maintainers, push your commits to your fork:
```
git push YOUR_FORK_REMOTE YOUR_BRANCH_NAME
```
Open a Pull Request. The title should follow the same guidelines of the commit message (most of the times it can simply be the same than the first commit message).

Once all revisions are complete and approved, a maintainer will squash and merge your commits.

New components

New components should be added to the lab package at:

packages/lab/src/<COMPONENT_NAME>

Refer to our Component Guidelines for structure and conventions.
For contribution steps, see Submitting a Pull Request.

Coding Standards

We enforce consistent code style and formatting using ESLint and Prettier.

Most modern IDEs support these tools via plugins, helping you follow the project’s rules automatically.
You can also run the following commands locally to check and fix issues:

npm run lint
npm run prettier

Code that doesn’t meet our standards will fail in CI and block the merge.

Commit Message Guidelines

We follow the Conventional Commits specification to format commit messages consistently. This approach improves readability, makes it easier to understand the project’s history, and enables automated changelog generation.

Each commit message must begin with a type, optionally followed by a scope, to clearly communicate the purpose of the change:

type(scope): description

Common Types

feat: a feature that is visible for end users.
fix: a bugfix that is visible for end users.
chore: a change that doesn’t impact end users (e.g. chances to CI pipeline)
docs: a change on the documentation
refactor: a change in production code focused on readability, style and/or performance.
Others commit types are allowed, for example: style:, perf:, test:.

Examples

docs: correct spelling of CHANGELOG
feat(lang): add Polish language support
fix(button): minor typo in code, fixes #12

Testing

All new features and fixes must include test coverage. Test your changes by running:

npm run test

Our CI pipeline runs:

Accessibility checks (static a11y analysis)
End-to-end tests (Playwright)
Visual regression tests (Chromatic)

Please keep an eye on the pull request result for detailed feedback and ensure all tests pass before requesting a review.

Project Status Guidelines