Skip to content

Latest commit

 

History

History
123 lines (83 loc) · 5.48 KB

CONTRIBUTING.md

File metadata and controls

123 lines (83 loc) · 5.48 KB
Raw

Contribution guidelines

We welcome contributions to our project. Here are a few guidelines that will help you along the way:

Getting started

# Clone the repository
git clone git@github.com:lumada-design/hv-uikit-react.git
cd hv-uikit-react
# Install the dependencies
npm ci
# Start the storybook dev environment
npm run doc

Question or problem?

Use GitHub issues for bug reports and feature requests or one of our available communication channels for general support questions.

New components

New components should be contributed to the lab package in packages/lab/src/components/<COMPONENT_NAME>.

Check out our Component Guidelines for a guide on how to structure components, and the submitting a pull request on how to contribute it.

Submitting an issue

You can file new issues by selecting from our issue templates and filling out the issue template. Before submitting an issue, please search the repository, as your issue might have been already answered.

Bugs 🐛

If your issue appears to be a bug, please report it by opening a new bug report.

Even better if you submit a Pull Request with the fix instead.

Feature requests ✨

You can request a new feature by submitting an issue to this repo. Features can be new components or changes to existing components.

Please make sure your features are compliant with the NEXT Design System guidelines.

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

  1. Pull the latest master branch.
  2. Always work and submit pull requests from a branch: 
    git checkout -b YOUR_BRANCH_NAME master
  3. Make sure you follow our coding standards, and add new test cases where appropriate following the testing guidelines.
  4. Commit your changes using a descriptive commit message that follows our commit message guidelines.
  5. Once ready for feedback from other contributors and maintainers, push your commits to your fork: 
    git push YOUR_FORK_REMOTE YOUR_BRANCH_NAME
  6. 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).

Maintainers will be reviewing your work, making comments, asking questions and suggesting changes to be made before they merge your code. Once all revisions to your merge request are complete, a maintainer will squash and merge your commits for you.

That's it! Thank you for your contribution!

Coding standards

We enforce some style and formatting rules for source code using ESLint and Prettier. Most popular IDEs have plugins that will following our linting and formatting rules. Alternatively, you can run npm run lint and npm run prettier to get a report of the issues.

Any issues not fixed will be caught during CI, and will prevent merging.

Commit message guidelines

We enforce Conventional Commits specs over how our git commit messages should be formatted. This leads to more readable messages that are easy to follow when looking through the project history. The git commit messages are also used to generate the change log.

Commits must be prefixed with a type in order to communicate intent, an optional scope may be provided after a type.

Type

Must be one of the following:

  • 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): added polish language
fix(button): minor typos in code, fixes #12

Testing

If you add any features to our code, make sure to add tests so that your changes are covered.

Test your changes by running our test commands:

npm run test

We also execute regression tests in all pull requests and releases against the a11y standards (accessibility static analysis), end-to-end tests (using Playwright) and visual tests using Chromatic and Applitools. Please keep an eye on the pull request result for detailed feedback.