Skip to content

Latest commit

 

History

History
151 lines (109 loc) · 5.97 KB

CONTRIBUTING.md

File metadata and controls

151 lines (109 loc) · 5.97 KB
Raw

Contribution Guide

Thanks for wanting to contribute! This document describes some points about the contribution process for the JSCS Spellcheck ackage.

  1. Maintainers
  2. Pull Requests
  1. Filing Bugs
  2. Proposing Features
  3. Implementing Features
  4. Proposing Additional Presets
  5. Setting up Your Environment
  6. Commit Message Format

Maintainers

The maintainers of the project are:

  • Jackson Ray Hamilton (@jacksonrayhamilton).

The project is being developed by the community. Maintainers merge pull-requests and fix critical bugs. All other features and patches are welcomed to be implemented by community members.

Pull-requests

If you fixed or added something useful to the project, you can send a pull-request. It will be reviewed by a maintainer and accepted, or commented for rework, or declined.

Before submitting a PR
  1. Please review our suggested commit message format.
  2. Make sure you have tests for your modifications (we use Mocha and Assert)
  • Tests for rules are located in test/rules
  1. Run npm test locally to catch any JSHint and JSCS errors.
Why did you close my pull request or issue?

Nothing is worse than a project with hundreds of stale issues. To keep things orderly, the maintainers try to close/resolve issues as quickly as possible.

PR/Issue closing criteria

We'll close your PR or issue if:

  1. It's a duplicate of an existing issue
  2. Outside of the style-driven scope of the project
  3. You are unresponsive after a few days
  4. The bug is not reproducible
  5. The feature request or rule modification request introduces too much complexity (or too many edge cases) to the tool
  • We weigh a request's complexity with the value it brings to the community.

Please do not take offense if your ticket is closed. We're only trying to keep the number of issues manageable.

Filing Bugs

If you found an error, typo, or any other flaw in the project, please report it using GitHub Issues. Try searching the issues to see if there is an existing report of your bug or feature request.

When it comes to bugs, the more details you provide, the easier it is to reproduce the issue and the faster it could be fixed.

Some helpful datapoints to provide (if you can):

  1. A failing test would be amazing
  2. Code snippets that make jscs exhibit the issue
  3. The version of jscs that you're using
  4. Your operating system (Windows, Mac, or Linux)
  5. Screenshots

Unfortunately, sometimes a bug can only be reproduced in your project or in your environment, so the maintainers cannot reproduce it. In this case we welcome you to try fixing the bug; we'll be more than happy to take a look at (and possibly incorporate) the fix.

Proposing Features

If you've got an idea for a new feature, file an issue providing some details on your idea.

If it's a new rule that you're proposing:

  • Provide the possible configuration inputs
  • Look at the rules in the readme for examples
  • You'll also have to think about (and implement) the reverse rule (Before|After) or (Require|Disallow)
  • Provide snippets to show code that your rule deems as valid and invalid.
  • Check out the readme for examples

If you'd like to modify the possible values for existing rules:

  • Provide code snippets showing the need for additional configuration values

Implementing Features

It's likely that you'll have to implement feature requests or enhancements on your own. To do that, you'll need to be comfortable with JavaScript, Promises, Node.js, and familiar with Esprima's abstract syntax tree format.

All of the rules are located in lib/rules and the tests for the rules are in test/rules.

If you cannot implement the feature, but you feel that it would be helpful to others, you can create an issue on GitHub. If the maintainers feel that the issue satisfies our criteria for closing issues, your issue will be closed with a genuine thank you and an explanation for the closure.

Setting up your environment

  1. Fork the jscs-spellcheck repository
  2. Clone your fork to your local machine
  3. Run npm install in your local fork
  4. Consider setting up the appropriate JSCS editor package
  • We use JSCS to check this codebase
  1. Create a new branch for your fix: git checkout -b my-fix-branch master
  2. Implement your bug fix or feature request
  3. Implement the tests for your fix or feature
  4. Run npm test frequently to find stylistic errors before issuing a PR
  5. Commit your code with a commit message that follows our commit message format
  • If you don't feel comfortable with that format, no worries, we'll fix up your commit after merging your PR.
  • Try to have a single commit per modified/added rule

Commit Message Format

We adhere to the jQuery commit message guidelines.

This format can be achieved via:

  • git commit to open your editor to create a multi-line commit message
<rulename>: short message
<emptyline>
Long description (if useful)
<emptyline>
Closes gh-<pullRequestNumber>
Fixes #<issueNumber>

Example:

validateIndentation: remove array and object indentation validation

Fixes #627 - issue
Closes gh-545 - pull request

You can find other examples of this format by viewing recent commits made to master.