Skip to content
Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
Go to file
Cannot retrieve contributors at this time

Contributing to reSTYLE

  1. Fork reSTYLE
  1. Update the Issue Tracker
  • if there's already an open ticket, feel free to comment on it or ask any follow up questions
  • if there isn't a ticket, create one and let us know what you plan to do
  • we like to keep an open dialog with developers :)
  1. Code away!
  2. Update or create test cases for your changes
  3. Make sure all tests are passing $ npm test (or $ gulp test)
  4. Commit and push your changes (referencing any related issues in the comment)
  5. Finally, create a Pull Request


Don't be that guy that broke the build. Tests help us ensure that everything is functioning the way it should be and help us ensure back-compat, or provide a clean migration path.

When making changes to reSTYLE code, there should (almost always) be accompanying test cases. If you're modifying existing functionality, make sure the current tests are passing, or update them to be accurate. If you're adding new functionality, you must also add test cases to cover it's behavior.

All the test cases live in test/.

To run the test suite, simply run:

npm test

Coding Standards


  • Use two "soft spaces", not tabs for indentation
  • Always use proper indentation
  • Use $gulp eclint and $gulp eclint:fix to find and fix any whitespace convention issues, respectively


  • Functions, mixins, and variables should be lowercase and hyphenated (e.g. $this-is-awesome)
  • Functions, mixins, and global variables should be prefixed with -restyle--.
    • $-restyle--this-is-global
    • @function -restyle--my-func() ...
    • @mixin -restyle--my-mixin() ...
  • For public mixins and functions, provide a convenience alias (see aliases.scss)
  • Use !default appropriately
  • Use multi-line convention with each rule on a separate line
  • Use a semi-colon after every declaration (including the last declaration of a rule)
  • Use SassDoc syntax for documenting all methods


  • Follow the ESLint conventions. You can test syntax via $ gulp lint

Commit Messages

When submitting pull requests, please follow the conventions outlined in AngularJS Git Commit Message Conventions

This will help us triage pull requests more effectively as well as help us maintain an accurate CHANGELOG


Thanks for contributing and helping push the web forward.