Skip to content

Latest commit

 

History

History
137 lines (84 loc) · 3.75 KB

CONTRIBUTING.md

File metadata and controls

137 lines (84 loc) · 3.75 KB
Raw

Contributing to halyard.js

You are more than welcome to contribute to halyard.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.

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.

Documentation changes

Documentation changes can be requested by adding issues in the repository.

Submit your documentation changes by creating a Pull Request, following the GIT guidelines. If the change is minor, you can submit a Pull Request directly without creating an issue first.

Developing

Begin by installing all dependencies:

$ npm install

Building the project:

$ npm run build

The build result is located in /dist folder.

halyard.js and halyard-enigma-mixin.js are the dev builds, and halyard.min.js and halyard-enigma-mixin.min.js are the minified versions.

Running tests:

$ npm run test:unit
$ npm run test:integration

Linting files:

$ npm run lint

If you have issues with line-endings, make sure your git repository is set to LF (unix line-endings):

$ git config core.autocrlf false

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/halyard.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 "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 the following items are satisfied:

  • CircleCI is green
  • Commit message format is followed
  • CLA is signed

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.

WARNING: Squashing or reverting commits and force-pushing thereafter may remove GitHub comments on code that were previously made by you or others in your commits. Avoid any form of rebasing unless necessary.

Commit message format

There are currently no conventions on how to format commit messages. We'd like you to follow some rules on the content however:

  • Use the present form, e.g. Fix dynamic script generation
  • Be descriptive and avoid messages like Minor fix.
  • If the change is breaking an API, add a [breaking] tag in the message.

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.