Skip to content

Latest commit

 

History

History
72 lines (46 loc) · 4.57 KB

CONTRIBUTING.md

File metadata and controls

72 lines (46 loc) · 4.57 KB

KNoT Contributing Guide

This contribution guideline is derived from the Vue.js, Atom, Starship and Convetional Commits contribution guidelines.

🎉 First of all, thank you so much for taking the time to contribute to KNoT! 🎉

Secondly, before submitting your contribution, please make sure to take a moment and read through the guidelines for contributing to KNoT and its packages, which are hosted in the CESARBR Organization on GitHub:

Code of Conduct

This project and everyone participating in it is governed by the Contributor Code of Conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to our Slack Workspace.

Issue Reporting Guidelines

The issue list is reserved exclusively for bug reports and feature requests. For usage questions, please use the following resources:

Also try to search for your issue - it may have already been answered or even fixed in the development branch. However, if you find that an old, closed issue still persists in the latest version, you should open a new issue using the form below instead of commenting on the old issue.

Pull Request Guidelines

KNoT uses the GitHub flow as main versioning workflow:

  1. Fork this repository
  2. Create a new branch for each feature, fix or improvement, off of master: git checkout -b my-feature-branch
  3. Make some changes, committing them along the way (make sure to follow the Commit Convention guidelines)
  4. When your changes are ready for review, push your branch: git push origin my-feature-branch
  5. Create a pull request from your branch to CESARBR/master (make sure to fill in all Pull Request requirements)
  6. No need to assign the pull request to anyone, we'll review it when we can
  7. When the changes have been reviewed and approved, if there are no conflicts with the master branch, someone will rebase and merge for you. If there are conflicts, go to step 8
  8. If your branch has conflicts with the master branch, use interactive rebase to resolve conflicts: git rebase master -i, then git push -f to update your branch (this automatically updates the pull request)

It is very important to separate new features or improvements into separate feature branches, and to send a pull request for each branch. This allow us to review and pull in new features or improvements individually.

Development Setup

You will need Node.js and npm or yarn. If you need multiple Node.js versions, take a look at nvm-sh's nvm project.

After cloning the repo, install the project's dependencies with:

$ yarn

Commonly used NPM scripts

# build all dist files, including npm packages
$ npm run build

# run index.js
$ npm run start

# run the full test suite, including linting/type checking
$ npm test

There are some other scripts available in the scripts section of the package.json file.

The default test script will do the following: lint with ESLint -> unit tests. Please make sure to have this pass successfully before submitting a PR.

License

You must agree that your patch will be licensed under the repository's license, and when we change the license we will assume that you agreed with the change unless you object to the changes in time.