Skip to main contentSkip to site searchSkip to component search
Honeycomb

How to contribute

If you spot an inconsistency, bug, or wish to propose an improvement to the existing components, please first discuss the change you wish to make by contacting Team Hive or issuing a Honeycomb service desk request. There is a chance the thing you want is in progress already, and we don't want to waste you precious time.

Prerequisites

Before contributing to Honeycomb react, make sure you have the following tools installed:

  • Node.js v22 or above;
    • If you're on macOS, we highly recommend using nvm to help manage different Node.js versions.
  • Git

Getting started

Clone the repo, install dependencies and proceed reading below for more details

git clone git@git.flix.tech:user/ui/honeycomb-react.git
cd honeycomb-react && npm i

Available scripts

Starting react-styleguidist instance in a dev environment at http://localhost:6060:

npm start

Running light and basic playground at http://localhost:9090 targeting the app in ./playground/** to test out your ideas or play with existing components:

npm run playground

Under the hood

Check developer's guide to find out how things work inside and which best practices we try to follow.

Contribution workflow

Create a branch

We tend to follow a number of patterns when it comes to branch naming:

  • start your branch with a feature-, fix-, opt- or docs- prefix depending on the type of change you want to make;
  • include HNY service desk ticket number if present (e.g. feature-hny-27);
  • provide some meaningful naming (e.g. feature-hny-34-add-checkbox-error-state).

This makes our lives way easier when it comes to contribution tracking.

Git flow and merge requests

We follow the semantic versioning pattern when it comes to releases (see: http://semver.org/ for more info), in order to sustain development and maintain release cycles we have a certain git workflow in place.

Git flow

Schema bellow illustrates an example git workflow when it comes to developing and releasing, breaking, non-breaking changes and hotfixes.

git-flow

Here is a list of branches we utilize during development with a brief description added:

  • master protected branch, only merge commits from feature, major and patch/hotfix branches are accepted
  • major develop branch for next major release (produces next major release when merged to master)
  • feature feature branch, branches out from master or major, depending or the nature of change (breaking change produces major release and needs to be merged in major branch)
  • fix branches out of master to fix stuff (produces a patch release when merged to master)

Merge requests

Depending on the nature of change you need to target minor, major or master branches when creating a merge request. In vast majority of cases this would be a minor, although if you do a hotfix, master needs to be targeted, a breaking change require major as target branch for you MR. If you unsure, target minor and we'll figure out the rest.

Experimental components

Sometimes a project needs certain component which is quite complex, but you don't have time or capacity to think through other potential use cases and features, wanting to focus on the core things your project needs. If the case before contributing first make sure your use case can provide value to other teams and projects then follow these steps:

1. Reach out to us at Team Hive and create a Honeycomb service desk request with a proposal.

This creates a platform for discussion. Your request needs to include a description of your use case and also a set of other potential use cases for this component. It's important that the resulting experimental component delivers value in it's experimental stage beyond your project and team (this is basically the main reasoning for component to be part of Honeycomb);

2. Collaborate with a designer creating design assets for the component

If there is no design provided yet, please work with one of the designers to create a mockup in Honeycomb Alpha project in Figma;

3. Follow best practices and contribute your component with a feature set discussed

Here it's important you follow the guidelines and requirements we state for our components, try to think a bit ahead treating you contributed component as a base for more potential features and changes. Make it well documented and covered with tests so other people can continue working on it.

Credits

We wish to thank all developers for the great implementations we found in Gitlab as well as all the contributions of the Hackrcomb HackRday project for being a great inspiration.