Skip to content

Latest commit

 

History

History
164 lines (115 loc) · 4.25 KB

CONTRIBUTING.md

File metadata and controls

164 lines (115 loc) · 4.25 KB

Contributing

Setup | Commands | Unit Testing | Git Commit Guidelines

Setup

$ npm run bootstrap

Unit Testing

Running tests

$ npm run test

with coverage:

$ npm run coverage

Writing tests

Test can be asserted with Should.js :

test().should.be.type("string");

test().should.eql({ foo: "foo", bar: "bar" });

test().should.be.equal("foobar");
import should from "should";

should.throws(() => {
  throw new ArgumentError();
}, /ArgumentError/);
it("Should fail", () => {
  return testAsync().should.be.rejectedWith("Error message");
});
import should from "should";

should.equal(test(), null);

should("foobar" == "foobar").be.ok;

Commands

All commands should be run at the root path of the project.

Command Description
$ npm run bootstrap Setup the project for development
$ npm run build Build (with babel)
$ npm run clean Delete all temporary files (NPM, build, etc.)
$ npm run clean:build Delete build files (babel, etc.)
$ npm run clean:npm Delete NPM generated files (node_modules, logs, etc.)
$ npm run coverage Run unit tests with code coverage
$ npm run style Check code style
$ npm run test Run tests
$ npm run validate Check the code is valid by checking code style and running tests

Git Commit Guidelines

Write meaningful and straightforward commit summaries.

# Bad
git commit assets -m 'change something' # ORLY? What change?

# Good
git commit assets -m 'style(css): Switch `reset.css` to `normalize.css`'

Avoid long commit summaries by limiting the maximum characters to 50.

Detailed descriptions should go on the commit message.

# Bad
git commit assets/javascripts -m 'Add `FIXME` note to dropdown module because it wasnt working on IE8'

# Good
git commit assets/javascripts -m 'style(dropdown): Add `FIXME` note to dropdown module'

Write commit summaries in the imperative, present tense.

# Bad
git commit scripts -m 'Fixed CI integration'

# Bad
git commit scripts -m 'Fixes CI integration'

# Bad
git commit scripts -m 'Fixing CI integration'

# Good
git commit scripts -m 'fix(ci): Fix CI integration'

Use proper english writing on commits.

Because SCM is also code documentation.

# Bad (Everything in lower case, no proper punctuation and "whatever" really?)
git commit assets/stylesheets -m 'update clearfix or whatever'

# Bad (Why are you screaming?)
git commit assets/stylesheets -m 'UPDATE CLEARFIX'

# Good (Meaningful commit summary with proper orthography)
git commit assets/stylesheets -m 'fix(clearfix): Update clearfix implementation to use a more modern approach'

Type

Must be one of the following:

Prefix Description
feat A new feature
fix A bug fix
docs Documentation only changes
style Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
refactor A code change that neither fixes a bug or adds a feature
test Adding missing tests
chore Changes to the build process or auxiliary tools and libraries such as documentation generation

Scope

The scope could be anything specifying place of the commit change. For example readme, package.json, OptionManager, docs/Components, etc...

Subject

The subject contains succinct description of the change:

  • Use the imperative, present tense: "change" not "changed" nor "changes"
  • Capitalize first letter
  • No dot (.) at the end

Body

Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior.

About

Those rules have been inspired by AngularJS contributing page and Netshoes styleguide.