Skip to content

Latest commit

 

History

History
89 lines (63 loc) · 3.61 KB

CONTRIBUTING.md

File metadata and controls

89 lines (63 loc) · 3.61 KB
Raw

Contributing

We use several pieces of technology in this repository to streamline the release process whilst maintaining high code quality.

Debugging WASM

By default if an error is un-handled (e.g a panic! in rust) when executing the WASM based module it will result in an un-helpful general error of RuntimeError: unreachable, which can be difficult to debug. To improve this experience, by default running yarn build in this library will compile the WASM from the rust with console feature enabled which provides a more insightful stacktrace for the error.

Pre pull request checklist

Below is a brief checklist prior to submitting or updating a pull request

  1. Commit messages conform to the below conventions.
  2. The pull request description fills in the relevant fields provided by the template.

Commit messages

A well formed commit message communicates context about a change. A diff will tell you what changed. A well cared for commit log is a beautiful and useful thing.

What may be a hassle at first soon becomes habit, and eventually a source of pride and productivity for all involved. From reviews to maintenance it's a powerful tool. Understanding why something happened months or years ago becomes not only possible but efficient.

We rely on consistent commit messages as we use conventional-changelog which automatically generates the changelog diff based on the commit messages

We enforce well formed commit messages with pre-commit hooks using husky.

The following guidelines are based on the angular team's contribution guide. Checkout commitizen and commitlint.io for assistance.

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

Type

Must be one of the following:

  • build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
  • ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
  • docs: Documentation only changes
  • feat: A new feature
  • fix: A bug fix
  • perf: A code change that improves performance
  • refactor: A code change that neither fixes a bug nor adds a feature
  • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
  • test: Adding missing tests or correcting existing tests

Scope

The scope should be the name of the module/package/area affected (as perceived by the person reading the commit message).

Subject

The subject contains a succinct description of the change.

  • use the imperative, present tense: "change" not "changed" nor "changes" (this convention matches up with commit messages generated by commands like git merge and git revert)
  • don't capitalise the first letter
  • no dot (.) at the end

Body

The body contains more detailed explanatory text, if necessary.

  • must have blank line between subject and body (unless you omit the body)
  • wrap at 72 chars
  • use the imperative, present tense: "change" not "changed" nor "changes" (this convention matches up with commit messages generated by commands like git merge and git revert)
  • should include the motivation for the change and contrast this with previous behaviour
  • paragraphs come after blank lines
  • use of markdown is encourage i.e. links, bullet points

Footer

The footer contains references to issues the commit closes or addresses.