Thanks for wanting to contribute! This document describes some points about the contribution process for the JSCS package.
The maintainers of the project are:
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.
Many of the community requests/issues relate new rule requests, supporting additional style variations via extending the supported options of a rule, bug fixes for existing rules, or strengthening presets by specifying more rules. All of those issues are great starting places for beginners to contribute.
If you'd like to work on an issue, just leave a comment on the issue saying that you'll work on a PR.
Also check out the beginner-friendly label for an additional set of beginner-friendly tickets.
Join us in the Gitter Chat Room.
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.
npm testlocally to catch any JSHint and JSCS errors.
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.
We'll close your PR or issue if:
Please do not take offense if your ticket is closed. We're only trying to keep the number of issues manageable.
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):
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.
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:
If you'd like to modify the possible values for existing rules:
It's likely that you'll have to implement feature requests or enhancements on your own. To do that, you'll need
Check out AST Explorer with the
To understand how JSCS works, the best place to start is in the
lib/ directory: starting with
(to see the processing flow when
jscs is invoked in the terminal) then going to
for understanding how JSCS checks files. The
lib/errors.js contain the internal data structures.
All of the rules are located in
lib/rules and the tests for the rules are in
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.
If you'd like to add an additional preset, please add the following (maintaining alphabetical order when possible):
npm installin your local fork
git checkout -b my-fix-branch master
npm testfrequently to find stylistic errors before issuing a PR
We adhere to the jQuery commit message guidelines.
This format can be achieved via:
git committo open your editor to create a multi-line commit message
<rulename>: short message <emptyline> Long description (if useful) <emptyline> Closes gh-<pullRequestNumber> Fixes #<issueNumber>
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.