Getting started

If you're not an active developer on the Confetti team, to start contributing, please fork our source code on Github. If you are, you'll already have access to the main repo, so forget about forks. Currently, the codebase contains both the Storybook and the Confetti's own source code, so please read the docs.

Branching model

We currently use Trunk based development for contributions

Trunk based repositories have only one permanent branch: main. From it, we can create feature and hotfix branches.

The only main rule is that main should always, always be stable. For that, be sure to run the tests (details on how to are in the Setup docs) before pushing your code and never push with the --no-validate flag, unless specifically being asked to.

Also, read our Pull Request Template carefully before opening a PR. It's really important, so that we can prevent common problems before reviewing.

Let's detail the branches and their roles:

Feature branches

Feature branches are used to develop new features for an upcoming or distant future release. If you're contributing with a feature or with a non-urgent bugfix, this is the type of branch we recommend you to use. They should exist as long as the feature is in development, and, in this case, should be as short-lived as possible. When the feature is done, open the PR for our main codebase, to the main branch, for review. After reviewed, it will at some point be merged back into branch main.

Hotfix branches

Yes, it's mostly the same kind of branch as the feature ones, but used for emergency purposes. It has a different name, so that we can track on the git history what was a hotfix and what was a feature.

If you're not from Labcodes or is not closely involved with the development of Confetti, we'd recommend never to use this type of branch.

Semantic versioning

For managing the versions of the @labcodes/confetti-ds project, we use semantic versioning. Please be sure to read it carefully, or, if you speak portuguese, take a look at our video on how it works.

Publishing new versions on NPM

After merging a branch into main on the @labcodes/confetti-ds repo, it's imperative that we generate a new version and publish it. To do that, we need to follow the following steps:

• merge the branch into main;
• create a new version number based on the currect one and apply it to package.json
• create a git tag for that new version;
• push the changes to main.

If you speak portuguese and want to understand better about NPM and how we use it in our Jira workflow, take a look at this video about NPM publishing and this one about our workflow.

Styling conventions

In this project, we use our own CSS guidelines, based on a flavor of BEM. Please take some time to read our guidelines before contributing with CSS code for the UI.