Skip to content

Latest commit

 

History

History
134 lines (85 loc) · 4.17 KB

CONTRIBUTING.md

File metadata and controls

134 lines (85 loc) · 4.17 KB
Raw

Contributing to picasso.js

You are more than welcome to contribute to picasso.js! Follow these guidelines and you will be ready to start:

Code of conduct

Please read and follow our Code of conduct

Bugs

Bugs can be reported by adding issues in the repository. Submit your bug fix by creating a Pull Request, following the GIT guidelines.

Please make sure to browse through existing issues before creating a new one.

Features

Features can be requested by adding issues in the repository. If the feature includes new designs or bigger changes, please be prepared to discuss the changes with us so we can cooperate on how to best include them.

Submit your feature by creating a Pull Request, following the GIT guidelines. Include any related documentation changes.

Developing

Prerequisites

Project structure

This is a multi-package repository which uses lerna for package task management and publishing.

  • docs/: contains documentation templates
  • examples/: contains simple examples of usage
  • plugins/: contains plugin packages
  • packages/picasso.js: contains the main picasso.js package
  • scripts/: contains build scripts
  • test/: contains test configs

Building

To install and build all packages run:

$ pnpm
$ pnpm build

This will generate UMD packages for:

  • the main package under /packages/picasso.js/dist
  • each plugin under /plugins/*/dist

Development workflow

  • pnpm build generates UMD bundles for all packages
  • pnpm lint checks code style
  • pnpm test runs all tests

Git Guidelines

Generally, development should be done directly towards the master branch.

Workflow

  1. Fork and clone the repository

    git clone [email protected]:YOUR-USERNAME/picasso.js.git

  2. Create a branch in the fork

    The branch should be based on the master branch in the master repository.

    git checkout -b my-feature-or-bugfix master

  3. Commit changes on your branch

    Commit changes to your branch, following the commit message format.

    git commit -m "fix: properly formatted SET statements."

  4. Push the changes to your fork

    git push -u myfork my-feature-or-bugfix

  5. Create a Pull Request

    Before creating a Pull Request, make sure to sign the CLA

    In the Github UI of your fork, create a Pull Request to the master branch of the master repository.

    If the branch has merge conflicts or has been outdated, please do a rebase against the master branch.

Commit message guidelines

Commit messages should follow the commit message convention.

Type

Should be one of the following:

  • build: Changes that affect the build system or external dependencies
  • chore: Changes to build and dev processes/tools
  • ci: Changes to the CI configuration files and scripts
  • docs: Changes to documentation
  • feat: A new feature
  • fix: A bug fix
  • perf: A code change that improves performance
  • refactor: Changes to production code that is neither a new feature nor a bug fix
  • revert: Reverts a previous commit
  • style: Changes to code style formatting (white space, commas etc)
  • test: Changes in test cases of production code

Scope

The <scope> of the commit is optional and can be omitted. When used though, it should describe the place or part of the project, e.g. docs(examples), feat(data) etc.

Signing the CLA

We need you to sign our Contributor License Agreement (CLA) before we can accept your Pull Request. Visit this link for more information: https://github.com/qlik-oss/open-source/blob/master/sign-cla.md.