Large diffs are not rendered by default.

@@ -0,0 +1,73 @@
# Working with Custom Parsers

If you want to use your own parser and provide additional capabilities for your rules, you can specify your own custom parser. If a `parseForESLint` method is exposed on the parser, this method will be used to parse the code. Otherwise, the `parse` method will be used. Both methods should take in the source code as the first argument, and an optional configuration object as the second argument (provided as `parserOptions` in a config file). The `parse` method should simply return the AST. The `parseForESLint` method should return an object that contains the required property `ast` and optional properties `services`, `scopeManager`, and `visitorKeys`.

* `ast` should contain the AST.
* `services` can contain any parser-dependent services (such as type checkers for nodes). The value of the `services` property is available to rules as `context.parserServices`. Default is an empty object.
* `scopeManager` can be a [ScopeManager](./scope-manager-interface.md) object. Custom parsers can use customized scope analysis for experimental/enhancement syntaxes. Default is the `ScopeManager` object which is created by [eslint-scope](https://github.com/eslint/eslint-scope).
* Support for `scopeManager` was added in ESLint v4.14.0. ESLint versions which support `scopeManager` will provide an `eslintScopeManager: true` property in `parserOptions`, which can be used for feature detection.
* `visitorKeys` can be an object to customize AST traversal. The keys of the object are the type of AST nodes. Each value is an array of the property names which should be traversed. Default is [KEYS of `eslint-visitor-keys`](https://github.com/eslint/eslint-visitor-keys#evkkeys).
* Support for `visitorKeys` was added in ESLint v4.14.0. ESLint versions which support `visitorKeys` will provide an `eslintVisitorKeys: true` property in `parserOptions`, which can be used for feature detection.

You can find an ESLint parser project [here](https://github.com/typescript-eslint/typescript-eslint).

```json
{
"parser": "./path/to/awesome-custom-parser.js"
}
```

```javascript
var espree = require("espree");
// awesome-custom-parser.js
exports.parseForESLint = function(code, options) {
return {
ast: espree.parse(code, options),
services: {
foo: function() {
console.log("foo");
}
},
scopeManager: null,
visitorKeys: null
};
};
```

## The AST specification

The AST that custom parsers should create is based on [ESTree](https://github.com/estree/estree). The AST requires some additional properties about detail information of the source code.

### All nodes:

All nodes must have `range` property.

* `range` (`number[]`) is an array of two numbers. Both numbers are a 0-based index which is the position in the array of source code characters. The first is the start position of the node, the second is the end position of the node. `code.slice(node.range[0], node.range[1])` must be the text of the node. This range does not include spaces/parentheses which are around the node.
* `loc` (`SourceLocation`) must not be `null`. [The `loc` property is defined as nullable by ESTree](https://github.com/estree/estree/blob/25834f7247d44d3156030f8e8a2d07644d771fdb/es5.md#node-objects), but ESLint requires this property. On the other hand, `SourceLocation#source` property can be `undefined`. ESLint does not use the `SourceLocation#source` property.

The `parent` property of all nodes must be rewriteable. ESLint sets each node's `parent` property to its parent node while traversing, before any rules have access to the AST.

### The `Program` node:

The `Program` node must have `tokens` and `comments` properties. Both properties are an array of the below Token interface.

```ts
interface Token {
type: string;
loc: SourceLocation;
range: [number, number]; // See "All nodes:" section for details of `range` property.
value: string;
}
```

* `tokens` (`Token[]`) is the array of tokens which affect the behavior of programs. Arbitrary spaces can exist between tokens, so rules check the `Token#range` to detect spaces between tokens. This must be sorted by `Token#range[0]`.
* `comments` (`Token[]`) is the array of comment tokens. This must be sorted by `Token#range[0]`.

The range indexes of all tokens and comments must not overlap with the range of other tokens and comments.

### The `Literal` node:

The `Literal` node must have `raw` property.

* `raw` (`string`) is the source code of this literal. This is the same as `code.slice(node.range[0], node.range[1])`.

Large diffs are not rendered by default.

@@ -32,7 +32,7 @@ module.exports.schema = []; // no options

## Rule Basics

`schema` (array) specifies the [options](#options-schemas) so ESLint can prevent invalid [rule configurations](../user-guide/configuring#configuring-rules)
`schema` (array) specifies the [options](#options-schemas) so ESLint can prevent invalid [rule configurations](../user-guide/configuring.md#configuring-rules)

`create` (function) returns an object with methods that ESLint calls to "visit" nodes while traversing the abstract syntax tree (AST as defined by [ESTree](https://github.com/estree/estree)) of JavaScript code:

@@ -42,7 +42,7 @@ module.exports.schema = []; // no options

A rule can use the current node and its surrounding tree to report or fix problems.

Here are methods for the [array-callback-return](../rules/array-callback-return) rule:
Here are methods for the [array-callback-return](../rules/array-callback-return.md) rule:

```js
function checkLastSegment (node) {
@@ -72,7 +72,7 @@ module.exports = function(context) {

The `context` object contains additional functionality that is helpful for rules to do their jobs. As the name implies, the `context` object contains information that is relevant to the context of the rule. The `context` object has the following properties:

* `parserOptions` - the parser options configured for this run (more details [here](../user-guide/configuring#specifying-parser-options)).
* `parserOptions` - the parser options configured for this run (more details [here](../user-guide/configuring.md#specifying-parser-options)).
* `id` - the rule ID.
* `options` - an array of rule options.
* `settings` - the `settings` from configuration.
@@ -476,7 +476,7 @@ valid: [
]
```

The options available and the expected syntax for `parserOptions` is the same as those used in [configuration](../user-guide/configuring#specifying-parser-options).
The options available and the expected syntax for `parserOptions` is the same as those used in [configuration](../user-guide/configuring.md#specifying-parser-options).

### Write Several Tests

@@ -571,5 +571,5 @@ The thing that makes ESLint different from other linters is the ability to defin
Runtime rules are written in the same format as all other rules. Create your rule as you would any other and then follow these steps:

1. Place all of your runtime rules in the same directory (i.e., `eslint_rules`).
2. Create a [configuration file](../user-guide/configuring) and specify your rule ID error level under the `rules` key. Your rule will not run unless it has a value of `1` or `2` in the configuration file.
3. Run the [command line interface](../user-guide/command-line-interface) using the `--rulesdir` option to specify the location of your runtime rules.
2. Create a [configuration file](../user-guide/configuring.md) and specify your rule ID error level under the `rules` key. Your rule will not run unless it has a value of `1` or `2` in the configuration file.
3. Run the [command line interface](../user-guide/command-line-interface.md) using the `--rulesdir` option to specify the location of your runtime rules.

Large diffs are not rendered by default.

@@ -2,18 +2,22 @@

This guide is intended for those who work as part of the ESLint project team.

## [Managing Issues](issues.html)
## [Managing Issues](issues.md)

Describes how to deal with issues when they're opened, when interacting with users, and how to close them effectively.

## [Reviewing Pull Requests](pullrequests.html)
## [Reviewing Pull Requests](pullrequests.md)

Describes how to review incoming pull requests.

## [Managing Releases](releases.html)
## [Managing Releases](releases.md)

Describes how to do an ESLint project release.

## [Governance](governance.html)
## [Governance](governance.md)

Describes the governance policy for ESLint, including the rights and privileges of individuals inside the project.

## [Working Groups](working-groups.md)

Describes how working groups are created and how they function within the ESLint project.
@@ -41,16 +41,38 @@ New Committers can be nominated by any existing Committer. Once they have been n

It is important to recognize that committership is a privilege, not a right. That privilege must be earned and once earned it can be removed by the TSC members by a standard TSC motion. However, under normal circumstances committership exists for as long as the Committer wishes to continue engaging with the project.

A Committer who shows an above-average level of contribution to the project, particularly with respect to its strategic direction and long-term health, may be nominated to become a TSC member, described below.
A Committer who shows an above-average level of contribution to the project, particularly with respect to its strategic direction and long-term health, may be nominated to become a reviewer, described below.

#### Process for Adding Committers

1. Send email congratulating the new committer and confirming that they would like to accept. This should also outline the responsibilities of a committer with a link to the maintainer guide.
1. Add the GitHub user to the "ESLint Team" team
2. Send welcome email with link to maintainer guide
3. Add committer email to the ESLint team mailing list
4. Add committer to the README
5. Invite to Gitter team chatroom
6. Tweet congratulations to the new committer from the ESLint Twitter account
1. Add committer email to the ESLint team mailing list
1. Invite to Gitter team chatroom
1. Tweet congratulations to the new committer from the ESLint Twitter account

### Reviewers

Reviewers are community members who have contributed a significant amount of time to the project through triaging of issues, fixing bugs, implementing enhancements/features, and are trusted community leaders.

Reviewers may perform all of the duties of Committers, and also:

* May merge external pull requests for accepted issues upon reviewing and approving the changes.
* May merge their own pull requests once they have collected the feedback they deem necessary. (No pull request should be merged without at least one Committer/Reviewer/TSC member comment stating they've looked at the code.)

To become a Reviewer:

* Work in a helpful and collaborative way with the community.
* Have given good feedback on others' submissions and displayed an overall understanding of the code quality standards for the project.
* Commit to being a part of the community for the long-term.
* Have submitted a minimum of 50 qualifying pull requests.

A Committer is invited to become a Reviewer by existing Reviewers and TSC members. A nomination will result in discussion and then a decision by the TSC.

#### Process for Adding Reviewers

1. Add the GitHub user to the "ESLint Reviewers" GitHub team
1. Tweet congratulations to the new Reviewer from the ESLint Twitter account

### Technical Steering Committee (TSC)

@@ -75,30 +97,35 @@ No more than 1/3 of the TSC members may be affiliated with the same employer. If

TSC members have additional responsibilities over and above those of a Committer. These responsibilities ensure the smooth running of the project. TSC members are expected to review code contributions, approve changes to this document, manage the copyrights within the project outputs, and attend regular TSC meetings.

TSC members fulfill all requirements of Committers, and also:
TSC members may perform all of the duties of Reviewers, and also:

* May merge external pull requests for accepted issues upon reviewing and approving the changes.
* May merge their own pull requests once they have collected the feedback they deem necessary. (No pull request should be merged without at least one Committer/TSC member comment stating they've looked at the code.)
* May release new versions of all ESLint projects.
* May participate in TSC meetings.
* May propose budget items.
* May propose new ESLint projects.

To become a TSC member:
There is no specific set of requirements or qualifications for TSC members beyond those that are expected of Reviewers.

* Work in a helpful and collaborative way with the community.
* Have given good feedback on others' submissions and displayed an overall understanding of the code quality standards for the project.
* Commit to being a part of the community for the long-term.
* Have submitted a minimum of 50 qualifying pull requests.
A Reviewer is invited to become a TSC member by existing TSC members. A nomination will result in discussion and then a decision by the TSC.

A Committer is invited to become a TSC member by existing TSC members. A nomination will result in discussion and then a decision by the TSC.
**Non-attending TSC Members:** TSC members who will be unavailable for meetings for any period of time may choose to be considered non-attending members. Non-attending members retain their TSC status but do not count as absent from meetings or votes. For instance, if the TSC has seven members with one non-attending member, the effective TSC size is six for meetings and votes. Non-attending members may still attending TSC meetings and participate in votes, in which case they are counted as an attending TSC member.

#### Process for Adding TSC Members

1. Add the GitHub user to the "ESLint TSC" team
2. Set the GitHub user to be have the "Owner" role for the ESLint organization
3. Send welcome email with link to maintainer guide
4. Add TSC member to the README
5. Invite to Gitter TSC chatroom
6. Make TSC member an admin on the ESLint team mailing list
7. Add TSC member as an admin to ESLint Twitter Account on Tweetdeck
8. Tweet congratulations to the new TSC member from the ESLint Twitter account
1. Add the GitHub user to the "ESLint TSC" GitHub team
1. Set the GitHub user to be have the "Owner" role for the ESLint organization
1. Send a welcome email with a link to the [maintainer guide](./) and the [npm 2FA guide](./npm-2fa).
1. Invite to the Gitter TSC chatroom
1. Make the TSC member an admin on the ESLint team mailing list
1. Add the TSC member to the recurring TSC meeting event on Google Calendar
1. Add the TSC member as an admin to ESLint Twitter Account on Tweetdeck
1. Add the TSC member to the ESLint TSC mailing list as an "Owner"
1. Tweet congratulations to the new TSC member from the ESLint Twitter account

#### Process for Adding Non-attending TSC Members

1. The TSC member informs the rest of the TSC about their non-attending status
1. The TSC member is added to the "Non-attending TSC" GitHub team

#### TSC Meetings

@@ -113,7 +140,7 @@ The intention of the agenda is not to approve or review all patches.
That should happen continuously on GitHub and be handled by the larger
group of Committers.

Any community member or committer can ask that something be added to
Any community member, Committer, or Reviewer can ask that something be added to
the next meeting's agenda by logging a GitHub Issue. Anyone can add the item to the agenda by adding
the "tsc agenda" tag to the issue.

@@ -124,7 +151,7 @@ cannot veto or remove items.

No binding votes on TSC agenda items can take place without a quorum of
TSC members present in the meeting. Quorum is achieved when more than
half of the TSC members are present.
half of the TSC members (minus non-attending members) are present.

The TSC may invite persons or representatives from certain projects to
participate in a non-voting capacity.
@@ -135,7 +162,7 @@ agenda item and sending it as a pull request after the meeting.
## Consensus Seeking Process

The TSC follows a
[Consensus Seeking](http://en.wikipedia.org/wiki/Consensus-seeking_decision-making)
[Consensus Seeking](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making)
decision making model.

When an agenda item has appeared to reach a consensus, the moderator
@@ -151,4 +178,4 @@ or else the discussion will continue. Simple majority wins.

This work is a derivative of [YUI Contributor Model](https://github.com/yui/yui3/wiki/Contributor-Model) and the [Node.js Project Governance Model](https://github.com/nodejs/node/blob/master/GOVERNANCE.md).

This work is licensed under a [Creative Commons Attribution-ShareAlike 2.0 UK: England & Wales License](http://creativecommons.org/licenses/by-sa/2.0/uk/).
This work is licensed under a [Creative Commons Attribution-ShareAlike 2.0 UK: England & Wales License](https://creativecommons.org/licenses/by-sa/2.0/uk/).
@@ -41,10 +41,10 @@ The steps for triaging an issue are:
* "documentation" - related to content on eslint.org
* "infrastructure" - related to resources needed for builds or deployment (VMs, CI tools, bots, etc.)
1. Once it's clear what type of issue it is, make sure all of the relevant information is provided:
* **Bugs**: See [bug reporting guidelines](/docs/developer-guide/contributing/reporting-bugs)
* **New Rules:** See [rule proposal guidelines](/docs/developer-guide/contributing/new-rules)
* **Rule Changes:** See [rule change proposal guidelines](/docs/developer-guide/contributing/rule-changes)
* **Other Changes:** See [change proposal guidelines](http://eslint.org/docs/developer-guide/contributing/changes)
* **Bugs**: See [bug reporting guidelines](/docs/developer-guide/contributing/reporting-bugs.md)
* **New Rules:** See [rule proposal guidelines](/docs/developer-guide/contributing/new-rules.md)
* **Rule Changes:** See [rule change proposal guidelines](/docs/developer-guide/contributing/rule-changes.md)
* **Other Changes:** See [change proposal guidelines](/docs/developer-guide/contributing/changes.md)
1. Next steps:
* **Questions:** answer the question and close the issue when the conversation is over.
* **Bugs:** if you can verify the bug, add the "accepted" label and ask if they would like to submit a pull request.
@@ -54,7 +54,7 @@ The steps for triaging an issue are:
* **Duplicates:** if you can verify the issue is a duplicate, add a comment mentioning the duplicate issue (such as, "Duplicate of #1234") and close the issue.
1. Regardless of the above, always leave a comment. Don't just add labels, engage with the person who opened the issue by asking a question (request more information if necessary) or stating your opinion of the issue. If it's a verified bug, ask if the user would like to submit a pull request.

**Note:** "Beginner" issues are intended to help new contributors feel welcome and empowered to make a contribution to ESLint. To ensure that new contributors are given a chance to work on these issues, issues labeled "beginner" must be open for 30 days *from the day the issue was labeled* before a team member is permitted to work on them.
**Note:** "Good first issue" issues are intended to help new contributors feel welcome and empowered to make a contribution to ESLint. To ensure that new contributors are given a chance to work on these issues, issues labeled "good first issue" must be open for 30 days *from the day the issue was labeled* before a team member is permitted to work on them.

## Accepting Issues

@@ -72,7 +72,7 @@ New rules and rule changes require a champion. As champion, it's your job to:
* Gain [consensus](#consensus) from the ESLint team on inclusion
* Guide the rule creation process until it's complete (so only champion a rule that you have time to implement or help another contributor implement)

Once consensus has been reached on inclusion, add the "accepted" and, optionally, "help wanted" and "beginner" labels, as necessary.
Once consensus has been reached on inclusion, add the "accepted" and, optionally, "help wanted" and "good first issue" labels, as necessary.

## Consensus

@@ -0,0 +1,16 @@
# npm two-factor authentication

The `eslint` npm account has two-factor authentication (2FA) enabled. The 2FA secret is distributed using a team on [Keybase](https://keybase.io). Anyone doing a release of a package from the Jenkins server needs to have access to the 2FA secret.

If you're on ESLint's TSC, you should perform the following steps to obtain the 2FA secret:

1. Download the [Keybase app](https://keybase.io/download) on a smartphone.
1. Open the app and create an account.
1. From the app, link your Keybase username with your GitHub username. (At the time of writing, the UI for this is to tap the face icon in the bottom-left of the app, then the profile picture in the top-right, then tap "Prove your GitHub" and follow the instructions.)
1. Mention your Keybase username in the team chatroom, and wait for someone to add you to the Keybase team.
1. Download an authenticator app like [Google Authenticator](https://support.google.com/accounts/answer/1066447) or [Authy](https://authy.com/), if you don't have one installed already.
1. In the Keybase app, navigate to the Keybase filesystem (at the time of writing, the UI for this is to tap the hamburger icon in the bottom-right, then tap "Files") and then navigate to `/team/eslint/auth`.
* If your authenticator app is downloaded on the same device as your Keybase app (this will usually be the case if you're using the Keybase mobile app), then open `npm_2fa_code.txt` and copy the contents to the clipboard. Open your authenticator app, and paste the contents as a new key (by selecting something like "Enter a provided key" or "Enter key manually").
* If your authenticator app is downloaded on a *different* device from your Keybase app (e.g. if you're using a Keybase desktop app), then open `npm_2fa_code.png` and scan it as a QR code from your authenticator app.

You should now be able to generate 6-digit 2FA codes for the `eslint` npm account using your authenticator app.
@@ -11,14 +11,15 @@ Anyone, both team members and the public, may leave comments on pull requests.
When a pull request is opened, the bot will check the following:

1. Has the submitter signed a CLA?
1. Is the commit message summary in the correct format? Double-check that the tag ("Fix:", "New:", etc.) is correct based on the issue. Documentation-only pull requests do not require an issue.
1. Does the commit summary reference an issue?
1. Is the commit message summary in the correct format?
1. Is the commit summary too long?

The bot will add a comment specifying the problems that it finds. You do not need to look at the pull request any further until those problems have been addressed (there's no need to comment on the pull request to ask the submitter to do what the bot asked - that's why we have the bot!).

Once the bot checks have been satisfied, you check the following:

1. Double-check that the commit message tag ("Fix:", "New:", etc.) is correct based on the issue (or, if no issue is referenced, based on the stated problem).
1. If the pull request makes a change to core, ensure that an issue exists and the pull request references the issue in the commit message.
1. Does the code follow our conventions (including header comments, JSDoc comments, etc.)? If not, please leave that feedback and reference the conventions document.
1. For code changes:
* Are there tests that verify the change? If not, please ask for them.
@@ -37,7 +38,8 @@ Committers may merge a pull request if it is a non-breaking change and is:
1. A documentation change
1. A bug fix (for either rules or core)
1. A dependency upgrade
1. Related to the build system
1. Related to the build tool
1. A chore

In addition, committers may merge any non-breaking pull request if it has been approved by at least one TSC member.

@@ -57,7 +59,7 @@ Team members may merge a pull request immediately if it:

1. Makes a small documentation change
1. Is a chore
1. Fixes a block of other work on the repo (build-related, test-related, dependency-related, etc.)
1. Fixes a block of other work on the repository (build-related, test-related, dependency-related, etc.)
1. Is an important fix to get into a patch release

Otherwise, team members should observe a waiting period before merging a pull request:
@@ -67,6 +69,8 @@ Otherwise, team members should observe a waiting period before merging a pull re

The waiting period ensures that other team members have a chance to review the pull request before it is merged.

If the pull request was created from a branch on the `eslint/eslint` repository (as opposed to a fork), delete the branch after merging the pull request. (GitHub will display a "Delete branch" button after the pull request is merged.)

**Note:** You should not merge your own pull request unless you're received feedback from at least one other team member.

## When to Close a Pull Request
@@ -2,7 +2,7 @@

Releases are when a project formally publishes a new version so the community can use it. There are two types of releases:

* Regular releases that follow [semantic versioning](http://semver.org/) and are considered production-ready.
* Regular releases that follow [semantic versioning](https://semver.org/) and are considered production-ready.
* Prereleases that are not considered production-ready and are intended to give the community a preview of upcoming changes.

## Release Team
@@ -16,6 +16,12 @@ A two-person release team is assigned to each scheduled release. This two-person

The two-person team should seek input from the whole team on the Monday following a release to double-check if a patch release is necessary.

At least one member of the release team needs to have access to [eslint's two-factor authentication for npm](./npm-2fa) in order to do a release.

## Release Communication

Each scheduled release should be associated with a release issue ([example](https://github.com/eslint/eslint/issues/8138)). The release issue is the source of information for the team about the status of a release. Be sure the release issue has the "release" label so that it's easy to find.

## Process

On the day of a scheduled release, the release team should follow these steps:
@@ -24,13 +30,16 @@ On the day of a scheduled release, the release team should follow these steps:
* Have been open at least two days and have been reviewed (these are just waiting for merge).
* Important pull requests (as determined by the team). You should stop and have people review before merging if they haven't been already.
* Documentation changes.
* Small bug fixes written by a team member.
* Small bugfixes written by a team member.
1. Log into Jenkins and schedule a build for the "ESLint Release" job.
1. Wait for the "ESLint Release" job to complete.
1. Update the release blog post with a "Highlights", including new rules and anything else that's important.
1. Make release announcement in the chatroom.
1. Make release announcement on Twitter.
1. Remind the team not to merge anything other than documentation changes and bug fixes.
1. Watch the console output of the build on Jenkins. At some point, the build will pause and a link will be produced with an input field for a six-digit 2FA code.
1. Enter the current six-digit 2FA code from your authenticator app. (Also see: [npm-2fa](./npm-2fa))
1. Continue the build and wait for it to finish.
1. Update the release blog post with a "Highlights" section, including new rules and anything else that's important.
1. Make a release announcement in the public chatroom.
1. Make a release announcement on Twitter.
1. Make a release announcement on the release issue. Document any problems that occurred during the release, and remind the team not to merge anything other than documentation changes and bugfixes. Leave the release issue open.
1. Add the `patch release pending` label to the release issue. (When this label is present, `eslint-github-bot` will create a pending status check on non-semver-patch pull requests, to ensure that they aren't accidentally merged while a patch release is pending.)

On the Monday following the scheduled release, the release team needs to determine if a patch release is necessary. A patch release is considered necessary if any of the following occurred since the scheduled release:

@@ -39,7 +48,9 @@ On the Monday following the scheduled release, the release team needs to determi

The patch release decision should be made as early on Monday as possible. If a patch release is necessary, then follow the same steps as the scheduled release process.

After the patch release has been published (or no patch release is necessary), inform the team that they can start merging in changes again.
In rare cases, a second patch release might be necessary if the release is known to have a severe regression that hasn't been fixed by Monday. If this occurs, the release team should announce the situation on the release issue, and leave the issue open until all patch releases are complete. However, it's usually better to fix bugs for the next release cycle rather than doing a second patch release.

After the patch release has been published (or no patch release is necessary), close the release issue and inform the team that they can start merging in semver-minor changes again.

## Emergency Releases

@@ -0,0 +1,22 @@
# Working Groups

The ESLint TSC may form working groups to focus on a specific area of the project.

## Creating a Working Group

Working groups are created by sending an email to the team mailing list. Each working group:

1. Must have a GitHub team under the "ESLint Team" top-level GitHub team. (The GitHub team name should end with "WG" to distinguish it from other types of teams.)
1. Must have at least one TSC member.
1. May have any number of Committers and Reviewers.
1. Must have at least two members.

Active working groups are listed on the [team page](https://eslint.org/team).

## How Working Groups Work

Each working group is responsible for its own inner working. Working groups can decide how large or small they should be (so long as there is at least two members), when and who to add or remove from the working group, and how to accomplish their objectives.

Working groups may be temporary or permanent.

If working groups intend to make a significant change to the ESLint project, the proposal must still be approved by the TSC.
@@ -1,4 +1,4 @@
# Enforces getter/setter pairs in objects (accessor-pairs)
# Enforces getter/setter pairs in objects and classes (accessor-pairs)

It's a common mistake in JavaScript to create an object with just a setter for a property but never have a corresponding getter defined for it. Without a getter, you cannot read the property, so it ends up not being used.

@@ -32,10 +32,14 @@ This rule enforces a style where it requires to have a getter for every property

By activating the option `getWithoutSet` it enforces the presence of a setter for every property which has a getter defined.

By default, this rule checks only object literals and property descriptors. If you want this rule
to also check class declarations and class expressions, activate the option `enforceForClassMembers`.

## Options

* `setWithoutGet` set to `true` will warn for setters without getters (Default `true`).
* `getWithoutSet` set to `true` will warn for getters without setters (Default `false`).
* `enforceForClassMembers` set to `true` additionally applies this rule to class getters/setters (Default `false`).

### setWithoutGet

@@ -143,6 +147,106 @@ Object.defineProperty(o, 'c', {
```

### enforceForClassMembers

By default, this rule does not enforce getter/setter pairs in class declarations and class expressions,
as the default value for `enforceForClassMembers` is `false`.

When `enforceForClassMembers` is set to `true`:

* `"getWithoutSet": true` will also warn for getters without setters in classes.
* `"setWithoutGet": true` will also warn for setters without getters in classes.

Examples of **incorrect** code for `{ "getWithoutSet": true, "enforceForClassMembers": true }`:

```js
/*eslint accessor-pairs: ["error", { "getWithoutSet": true, "enforceForClassMembers": true }]*/
class Foo {
get a() {
return this.val;
}
}
class Bar {
static get a() {
return this.val;
}
}
const Baz = class {
get a() {
return this.val;
}
static set a(value) {
this.val = value;
}
}
```

Examples of **incorrect** code for `{ "setWithoutGet": true, "enforceForClassMembers": true }`:

```js
/*eslint accessor-pairs: ["error", { "setWithoutGet": true, "enforceForClassMembers": true }]*/
class Foo {
set a(value) {
this.val = value;
}
}
const Bar = class {
static set a(value) {
this.val = value;
}
}
```

## Known Limitations

Due to the limits of static analysis, this rule does not account for possible side effects and in certain cases
might not report a missing pair for a getter/setter that has a computed key, like in the following example:

```js
/*eslint accessor-pairs: "error"*/
var a = 1;
// no warnings
var o = {
get [a++]() {
return this.val;
},
set [a++](value) {
this.val = value;
}
};
```

Also, this rule does not disallow duplicate keys in object literals and class definitions, and in certain cases with duplicate keys
might not report a missing pair for a getter/setter, like in the following example:

```js
/*eslint accessor-pairs: "error"*/
// no warnings
var o = {
get a() {
return this.val;
},
a: 1,
set a(value) {
this.val = value;
}
};
```

The code above creates an object with just a setter for the property `"a"`.

See [no-dupe-keys](no-dupe-keys.md) if you also want to disallow duplicate keys in object literals.

See [no-dupe-class-members](no-dupe-class-members.md) if you also want to disallow duplicate names in class definitions.

## When Not To Use It

You can turn this rule off if you are not concerned with the simultaneous presence of setters and getters on objects.
@@ -0,0 +1,281 @@
# enforce line breaks after opening and before closing array brackets (array-bracket-newline)

A number of style guides require or disallow line breaks inside of array brackets.

## Rule Details

This rule enforces line breaks after opening and before closing array brackets.

## Options

This rule has either a string option:

* `"always"` requires line breaks inside brackets
* `"never"` disallows line breaks inside brackets
* `"consistent"` requires consistent usage of linebreaks for each pair of brackets. It reports an error if one bracket in the pair has a linebreak inside it and the other bracket does not.

Or an object option (Requires line breaks if any of properties is satisfied. Otherwise, disallows line breaks):

* `"multiline": true` (default) requires line breaks if there are line breaks inside elements or between elements. If this is false, this condition is disabled.
* `"minItems": null` (default) requires line breaks if the number of elements is at least the given integer. If this is 0, this condition will act the same as the option `"always"`. If this is `null` (the default), this condition is disabled.

### always

Examples of **incorrect** code for this rule with the `"always"` option:

```js
/*eslint array-bracket-newline: ["error", "always"]*/
var a = [];
var b = [1];
var c = [1, 2];
var d = [1,
2];
var e = [function foo() {
dosomething();
}];
```

Examples of **correct** code for this rule with the `"always"` option:

```js
/*eslint array-bracket-newline: ["error", "always"]*/
var a = [
];
var b = [
1
];
var c = [
1, 2
];
var d = [
1,
2
];
var e = [
function foo() {
dosomething();
}
];
```

### never

Examples of **incorrect** code for this rule with the `"never"` option:

```js
/*eslint array-bracket-newline: ["error", "never"]*/
var a = [
];
var b = [
1
];
var c = [
1, 2
];
var d = [
1,
2
];
var e = [
function foo() {
dosomething();
}
];
```

Examples of **correct** code for this rule with the `"never"` option:

```js
/*eslint array-bracket-newline: ["error", "never"]*/
var a = [];
var b = [1];
var c = [1, 2];
var d = [1,
2];
var e = [function foo() {
dosomething();
}];
```

### consistent

Examples of **incorrect** code for this rule with the `"consistent"` option:

```js
/*eslint array-bracket-newline: ["error", "consistent"]*/
var a = [1
];
var b = [
1];
var c = [function foo() {
dosomething();
}
]
var d = [
function foo() {
dosomething();
}]
```

Examples of **correct** code for this rule with the `"consistent"` option:

```js
/*eslint array-bracket-newline: ["error", "consistent"]*/
var a = [];
var b = [
];
var c = [1];
var d = [
1
];
var e = [function foo() {
dosomething();
}];
var f = [
function foo() {
dosomething();
}
];
```

### multiline

Examples of **incorrect** code for this rule with the default `{ "multiline": true }` option:

```js
/*eslint array-bracket-newline: ["error", { "multiline": true }]*/
var a = [
];
var b = [
1
];
var c = [
1, 2
];
var d = [1,
2];
var e = [function foo() {
dosomething();
}];
```

Examples of **correct** code for this rule with the default `{ "multiline": true }` option:

```js
/*eslint array-bracket-newline: ["error", { "multiline": true }]*/
var a = [];
var b = [1];
var c = [1, 2];
var d = [
1,
2
];
var e = [
function foo() {
dosomething();
}
];
```

### minItems

Examples of **incorrect** code for this rule with the `{ "minItems": 2 }` option:

```js
/*eslint array-bracket-newline: ["error", { "minItems": 2 }]*/
var a = [
];
var b = [
1
];
var c = [1, 2];
var d = [1,
2];
var e = [
function foo() {
dosomething();
}
];
```

Examples of **correct** code for this rule with the `{ "minItems": 2 }` option:

```js
/*eslint array-bracket-newline: ["error", { "minItems": 2 }]*/
var a = [];
var b = [1];
var c = [
1, 2
];
var d = [
1,
2
];
var e = [function foo() {
dosomething();
}];
```

### multiline and minItems

Examples of **incorrect** code for this rule with the `{ "multiline": true, "minItems": 2 }` options:

```js
/*eslint array-bracket-newline: ["error", { "multiline": true, "minItems": 2 }]*/
var a = [
];
var b = [
1
];
var c = [1, 2];
var d = [1,
2];
var e = [function foo() {
dosomething();
}];
```

Examples of **correct** code for this rule with the `{ "multiline": true, "minItems": 2 }` options:

```js
/*eslint array-bracket-newline: ["error", { "multiline": true, "minItems": 2 }]*/
var a = [];
var b = [1];
var c = [
1, 2
];
var d = [
1,
2
];
var e = [
function foo() {
dosomething();
}
];
```


## When Not To Use It

If you don't want to enforce line breaks after opening and before closing array brackets, don't enable this rule.

## Compatibility

* **JSCS:** [validateNewlineAfterArrayElements](https://jscs-dev.github.io/rule/validateNewlineAfterArrayElements)

## Related Rules

* [array-bracket-spacing](array-bracket-spacing.md)
@@ -1,7 +1,7 @@
# Enforces return statements in callbacks of array's methods (array-callback-return)

`Array` has several methods for filtering, mapping, and folding.
If we forget to write `return` statement in a callback of those, it's probably a mistake.
If we forget to write `return` statement in a callback of those, it's probably a mistake. If you don't want to use a return or don't need the returned results, consider using [.forEach](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/forEach) instead.

```js
// example: convert ['a', 'b', 'c'] --> {a: 0, b: 1, c: 2}
@@ -16,16 +16,16 @@ This rule enforces usage of `return` statement in callbacks of array's methods.

This rule finds callback functions of the following methods, then checks usage of `return` statement.

* [`Array.from`](http://www.ecma-international.org/ecma-262/6.0/#sec-array.from)
* [`Array.prototype.every`](http://www.ecma-international.org/ecma-262/6.0/#sec-array.prototype.every)
* [`Array.prototype.filter`](http://www.ecma-international.org/ecma-262/6.0/#sec-array.prototype.filter)
* [`Array.prototype.find`](http://www.ecma-international.org/ecma-262/6.0/#sec-array.prototype.find)
* [`Array.prototype.findIndex`](http://www.ecma-international.org/ecma-262/6.0/#sec-array.prototype.findIndex )
* [`Array.prototype.map`](http://www.ecma-international.org/ecma-262/6.0/#sec-array.prototype.map)
* [`Array.prototype.reduce`](http://www.ecma-international.org/ecma-262/6.0/#sec-array.prototype.reduce)
* [`Array.prototype.reduceRight`](http://www.ecma-international.org/ecma-262/6.0/#sec-array.prototype.reduceRight)
* [`Array.prototype.some`](http://www.ecma-international.org/ecma-262/6.0/#sec-array.prototype.some)
* [`Array.prototype.sort`](http://www.ecma-international.org/ecma-262/6.0/#sec-array.prototype.sort)
* [`Array.from`](https://www.ecma-international.org/ecma-262/6.0/#sec-array.from)
* [`Array.prototype.every`](https://www.ecma-international.org/ecma-262/6.0/#sec-array.prototype.every)
* [`Array.prototype.filter`](https://www.ecma-international.org/ecma-262/6.0/#sec-array.prototype.filter)
* [`Array.prototype.find`](https://www.ecma-international.org/ecma-262/6.0/#sec-array.prototype.find)
* [`Array.prototype.findIndex`](https://www.ecma-international.org/ecma-262/6.0/#sec-array.prototype.findindex)
* [`Array.prototype.map`](https://www.ecma-international.org/ecma-262/6.0/#sec-array.prototype.map)
* [`Array.prototype.reduce`](https://www.ecma-international.org/ecma-262/6.0/#sec-array.prototype.reduce)
* [`Array.prototype.reduceRight`](https://www.ecma-international.org/ecma-262/6.0/#sec-array.prototype.reduceright)
* [`Array.prototype.some`](https://www.ecma-international.org/ecma-262/6.0/#sec-array.prototype.some)
* [`Array.prototype.sort`](https://www.ecma-international.org/ecma-262/6.0/#sec-array.prototype.sort)
* And above of typed arrays.

Examples of **incorrect** code for this rule:
@@ -72,6 +72,21 @@ var foo = Array.from(nodes, function(node) {
var bar = foo.map(node => node.getAttribute("id"));
```

## Options

This rule has an object option:

* `"allowImplicit": false` (default) When set to true, allows implicitly returning `undefined` with a `return` statement containing no expression.

Examples of **correct** code for the `{ "allowImplicit": true }` option:

```js
/*eslint array-callback-return: ["error", { allowImplicit: true }]*/
var undefAllTheThings = myArray.map(function(item) {
return;
});
```

## Known Limitations

This rule checks callback functions of methods with the given names, *even if* the object which has the method is *not* an array.
@@ -0,0 +1,304 @@
# enforce line breaks between array elements (array-element-newline)

A number of style guides require or disallow line breaks between array elements.

## Rule Details

This rule enforces line breaks between array elements.

## Options

This rule has either a string option:

* `"always"` (default) requires line breaks between array elements
* `"never"` disallows line breaks between array elements
* `"consistent"` requires consistent usage of linebreaks between array elements

Or an object option (Requires line breaks if any of properties is satisfied. Otherwise, disallows line breaks):

* `"multiline": <boolean>` requires line breaks if there are line breaks inside elements. If this is false, this condition is disabled.
* `"minItems": <number>` requires line breaks if the number of elements is at least the given integer. If this is 0, this condition will act the same as the option `"always"`. If this is `null` (the default), this condition is disabled.

### always

Examples of **incorrect** code for this rule with the default `"always"` option:

```js
/*eslint array-element-newline: ["error", "always"]*/
var c = [1, 2];
var d = [1, 2, 3];
var e = [
function foo() {
dosomething();
}, function bar() {
dosomething();
}
];
```

Examples of **correct** code for this rule with the default `"always"` option:

```js
/*eslint array-element-newline: ["error", "always"]*/
var a = [];
var b = [1];
var c = [1,
2];
var d = [1,
2,
3];
var e = [
function foo() {
dosomething();
},
function bar() {
dosomething();
}
];
```

### never

Examples of **incorrect** code for this rule with the `"never"` option:

```js
/*eslint array-element-newline: ["error", "never"]*/
var c = [
1,
2
];
var d = [
1,
2,
3
];
var e = [
function foo() {
dosomething();
},
function bar() {
dosomething();
}
];
```

Examples of **correct** code for this rule with the `"never"` option:

```js
/*eslint array-element-newline: ["error", "never"]*/
var a = [];
var b = [1];
var c = [1, 2];
var d = [1, 2, 3];
var e = [
function foo() {
dosomething();
}, function bar() {
dosomething();
}
];
```

### consistent

Examples of **incorrect** code for this rule with the `"consistent"` option:

```js
/*eslint array-element-newline: ["error", "consistent"]*/
var a = [
1, 2,
3
];
var b = [
function foo() {
dosomething();
}, function bar() {
dosomething();
},
function baz() {
dosomething();
}
];
```

Examples of **correct** code for this rule with the `"consistent"` option:

```js
/*eslint array-element-newline: ["error", "consistent"]*/
var a = [];
var b = [1];
var c = [1, 2];
var d = [1, 2, 3];
var e = [
1,
2
];
var f = [
1,
2,
3
];
var g = [
function foo() {
dosomething();
}, function bar() {
dosomething();
}, function baz() {
dosomething();
}
];
var h = [
function foo() {
dosomething();
},
function bar() {
dosomething();
},
function baz() {
dosomething();
}
];
```

### multiline

Examples of **incorrect** code for this rule with the `{ "multiline": true }` option:

```js
/*eslint array-element-newline: ["error", { "multiline": true }]*/
var d = [1,
2, 3];
var e = [
function foo() {
dosomething();
}, function bar() {
dosomething();
}
];
```

Examples of **correct** code for this rule with the `{ "multiline": true }` option:

```js
/*eslint array-element-newline: ["error", { "multiline": true }]*/
var a = [];
var b = [1];
var c = [1, 2];
var d = [1, 2, 3];
var e = [
function foo() {
dosomething();
},
function bar() {
dosomething();
}
];
```

### minItems

Examples of **incorrect** code for this rule with the `{ "minItems": 3 }` option:

```js
/*eslint array-element-newline: ["error", { "minItems": 3 }]*/
var c = [1,
2];
var d = [1, 2, 3];
var e = [
function foo() {
dosomething();
},
function bar() {
dosomething();
}
];
```

Examples of **correct** code for this rule with the `{ "minItems": 3 }` option:

```js
/*eslint array-element-newline: ["error", { "minItems": 3 }]*/
var a = [];
var b = [1];
var c = [1, 2];
var d = [1,
2,
3];
var e = [
function foo() {
dosomething();
}, function bar() {
dosomething();
}
];
```

### multiline and minItems

Examples of **incorrect** code for this rule with the `{ "multiline": true, "minItems": 3 }` options:

```js
/*eslint array-element-newline: ["error", { "multiline": true, "minItems": 3 }]*/
var c = [1,
2];
var d = [1, 2, 3];
var e = [
function foo() {
dosomething();
}, function bar() {
dosomething();
}
];
```

Examples of **correct** code for this rule with the `{ "multiline": true, "minItems": 3 }` options:

```js
/*eslint array-element-newline: ["error", { "multiline": true, "minItems": 3 }]*/
var a = [];
var b = [1];
var c = [1, 2];
var d = [1,
2,
3];
var e = [
function foo() {
dosomething();
},
function bar() {
dosomething();
}
];
```


## When Not To Use It

If you don't want to enforce linebreaks between array elements, don't enable this rule.

## Compatibility

* **JSCS:** [validateNewlineAfterArrayElements](https://jscs-dev.github.io/rule/validateNewlineAfterArrayElements)

## Related Rules

* [array-bracket-spacing](array-bracket-spacing.md)
* [array-bracket-newline](array-bracket-newline.md)
* [object-property-newline](object-property-newline.md)
* [object-curly-spacing](object-curly-spacing.md)
* [object-curly-newline](object-curly-newline.md)
* [max-statements-per-line](max-statements-per-line.md)
* [block-spacing](block-spacing.md)
* [brace-style](brace-style.md)
@@ -52,7 +52,7 @@ This rule has a string option and an object one.
String options are:

* `"always"` (default) requires parens around arguments in all cases.
* `"as-needed"` allows omitting parens when there is only one argument.
* `"as-needed"` enforces no braces where they can be omitted.

Object properties for variants of the `"as-needed"` option:

@@ -1,8 +1,8 @@
# Disallow or enforce spaces inside of single line blocks (block-spacing)
# Disallow or enforce spaces inside of blocks after opening block and before closing block (block-spacing)

## Rule Details

This rule enforces consistent spacing inside single-line blocks.
This rule enforces consistent spacing inside an open block token and the next token on the same line. This rule also enforces consistent spacing inside a close block token and previous token on the same line.

## Options

@@ -20,6 +20,9 @@ Examples of **incorrect** code for this rule with the default `"always"` option:
function foo() {return true;}
if (foo) { bar = 0;}
function baz() {let i = 0;
return i;
}
```

Examples of **correct** code for this rule with the default `"always"` option:
@@ -1,6 +1,6 @@
# Require Brace Style (brace-style)

Brace style is closely related to [indent style](http://en.wikipedia.org/wiki/Indent_style) in programming and describes the placement of braces relative to their control statement and body. There are probably a dozen, if not more, brace styles in the world.
Brace style is closely related to [indent style](https://en.wikipedia.org/wiki/Indent_style) in programming and describes the placement of braces relative to their control statement and body. There are probably a dozen, if not more, brace styles in the world.

The *one true brace style* is one of the most common brace styles in JavaScript, in which the opening brace of a block is placed on the same line as its corresponding statement or declaration. For example:

@@ -301,4 +301,4 @@ If you don't want to enforce a particular brace style, don't enable this rule.

## Further Reading

* [Indent style](http://en.wikipedia.org/wiki/Indent_style)
* [Indent style](https://en.wikipedia.org/wiki/Indent_style)
@@ -167,7 +167,7 @@ There are some cases where you might want to call a callback function more than
## Further Reading

* [The Art Of Node: Callbacks](https://github.com/maxogden/art-of-node#callbacks)
* [Nodejitsu: What are the error conventions?](http://docs.nodejitsu.com/articles/errors/what-are-the-error-conventions)
* [Nodejitsu: What are the error conventions?](https://docs.nodejitsu.com/articles/errors/what-are-the-error-conventions/)

## Related Rules

@@ -1,6 +1,6 @@
# Require Camelcase (camelcase)
# Require CamelCase (camelcase)

When it comes to naming variables, style guides generally fall into one of two camps: camelcase (`variableName`) and underscores (`variable_name`). This rule focuses on using the camelcase approach. If your style guide calls for camelcasing your variable names, then this rule is for you!
When it comes to naming variables, style guides generally fall into one of two camps: camelcase (`variableName`) and underscores (`variable_name`). This rule focuses on using the camelcase approach. If your style guide calls for camelCasing your variable names, then this rule is for you!

## Rule Details

@@ -12,8 +12,11 @@ This rule has an object option:

* `"properties": "always"` (default) enforces camelcase style for property names
* `"properties": "never"` does not check property names
* `"ignoreDestructuring": false` (default) enforces camelcase style for destructured identifiers
* `"ignoreDestructuring": true` does not check destructured identifiers
* `allow` (`string[]`) list of properties to accept. Accept regex.

### always
### properties: "always"

Examples of **incorrect** code for this rule with the default `{ "properties": "always" }` option:

@@ -32,9 +35,27 @@ obj.do_something = function() {
// ...
};
function foo({ no_camelcased }) {
// ...
};
function foo({ isCamelcased: no_camelcased }) {
// ...
}
function foo({ no_camelcased = 'default value' }) {
// ...
};
var obj = {
my_pref: 1
};
var { category_id = 1 } = query;
var { foo: no_camelcased } = bar;
var { foo: bar_baz = 1 } = quz;
```

Examples of **correct** code for this rule with the default `{ "properties": "always" }` option:
@@ -56,9 +77,28 @@ do_something();
new do_something();
var { category_id: category } = query;
function foo({ isCamelCased }) {
// ...
};
function foo({ isCamelCased: isAlsoCamelCased }) {
// ...
}
function foo({ isCamelCased = 'default value' }) {
// ...
};
var { categoryId = 1 } = query;
var { foo: isCamelCased } = bar;
var { foo: isCamelCased = 1 } = quz;
```

### never
### properties: "never"

Examples of **correct** code for this rule with the `{ "properties": "never" }` option:

@@ -70,6 +110,72 @@ var obj = {
};
```

### ignoreDestructuring: false

Examples of **incorrect** code for this rule with the default `{ "ignoreDestructuring": false }` option:

```js
/*eslint camelcase: "error"*/
var { category_id } = query;
var { category_id = 1 } = query;
var { category_id: category_id } = query;
var { category_id: category_alias } = query;
var { category_id: categoryId, ...other_props } = query;
```

### ignoreDestructuring: true

Examples of **incorrect** code for this rule with the `{ "ignoreDestructuring": true }` option:

```js
/*eslint camelcase: ["error", {ignoreDestructuring: true}]*/
var { category_id: category_alias } = query;
var { category_id, ...other_props } = query;
```

Examples of **correct** code for this rule with the `{ "ignoreDestructuring": true }` option:

```js
/*eslint camelcase: ["error", {ignoreDestructuring: true}]*/
var { category_id } = query;
var { category_id = 1 } = query;
var { category_id: category_id } = query;
```

## allow

Examples of **correct** code for this rule with the `allow` option:

```js
/*eslint camelcase: ["error", {allow: ["UNSAFE_componentWillMount"]}]*/
function UNSAFE_componentWillMount() {
// ...
}
```

```js
/*eslint camelcase: ["error", {allow: ["^UNSAFE_"]}]*/
function UNSAFE_componentWillMount() {
// ...
}
function UNSAFE_componentWillMount() {
// ...
}
```

## When Not To Use It

If you have established coding standards using a different naming convention (separating words with underscores), turn this rule off.
@@ -175,7 +175,7 @@ If the `ignoreConsecutiveComments` option is set to `true`, then comments which
Examples of **correct** code with `ignoreConsecutiveComments` set to `true`:

```js
/* eslint capitalize-comments: ["error", "always", { "ignoreConsecutiveComments": true }] */
/* eslint capitalized-comments: ["error", "always", { "ignoreConsecutiveComments": true }] */
// This comment is valid since it has the correct capitalization.
// this comment is ignored since it follows another comment,
@@ -191,7 +191,7 @@ Examples of **correct** code with `ignoreConsecutiveComments` set to `true`:
Examples of **incorrect** code with `ignoreConsecutiveComments` set to `true`:

```js
/* eslint capitalize-comments: ["error", "always", { "ignoreConsecutiveComments": true }] */
/* eslint capitalized-comments: ["error", "always", { "ignoreConsecutiveComments": true }] */
// this comment is invalid, but only on this line.
// this comment does NOT get reported, since it is a consecutive comment.
@@ -245,4 +245,5 @@ This rule can be disabled if you do not care about the grammatical style of comm

## Compatibility

* **JSCS**: [requireCapitalizedComments](http://jscs.info/rule/requireCapitalizedComments) and [disallowCapitalizedComments](http://jscs.info/rule/disallowCapitalizedComments)
* **JSCS**: [requireCapitalizedComments](https://jscs-dev.github.io/rule/requireCapitalizedComments)
* **JSCS**: [disallowCapitalizedComments](https://jscs-dev.github.io/rule/disallowCapitalizedComments)
@@ -1,6 +1,6 @@
# Enforce that class methods utilize `this` (class-methods-use-this)

If a class method does not use `this`, it can safely be made a static function.
If a class method does not use `this`, it can *sometimes* be made into a static function. If you do convert the method into a static function, instances of the class that call that particular method have to be converted to a static call as well (`MyClass.callStaticMethod()`)

It's possible to have a class method which doesn't use `this`, such as:

@@ -43,7 +43,7 @@ class A {
A.sayHi(); // => "hi"
```

Also note in the above examples that the code calling the function on an *instance* of the class (`let a = new A(); a.sayHi();`) changes to calling it on the *class* itself (`A.sayHi();`).
Also note in the above examples that if you switch a method to a static method, *instances* of the class that call the static method (`let a = new A(); a.sayHi();`) have to be updated to being a static call (`A.sayHi();`) instead of having the instance of the *class* call the method

## Rule Details

@@ -94,7 +94,7 @@ class A {
"class-methods-use-this": [<enabled>, { "exceptMethods": [<...exceptions>] }]
```

The `exceptMethods` option allows you to pass an array of method names for which you would like to ignore warnings.
The `exceptMethods` option allows you to pass an array of method names for which you would like to ignore warnings. For example, you might have a spec from an external library that requires you to overwrite a method as a regular function (and not as a static method) and does not use `this` inside the function body. In this case, you can add that method to ignore in the warnings.

Examples of **incorrect** code for this rule when used without exceptMethods:

@@ -117,3 +117,8 @@ class A {
}
}
```

## Further Reading

* [Classes](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes)
* [Static Methods](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/static)
@@ -48,7 +48,7 @@ This rule has a string option or an object option:
"objects": "never",
"imports": "never",
"exports": "never",
"functions": "ignore",
"functions": "never"
}]
}
```
@@ -58,8 +58,6 @@ This rule has a string option or an object option:
* `"always-multiline"` requires trailing commas when the last element or property is in a *different* line than the closing `]` or `}` and disallows trailing commas when the last element or property is on the *same* line as the closing `]` or `}`
* `"only-multiline"` allows (but does not require) trailing commas when the last element or property is in a *different* line than the closing `]` or `}` and disallows trailing commas when the last element or property is on the *same* line as the closing `]` or `}`

Trailing commas in function declarations and function calls are valid syntax since ECMAScript 2017; however, the string option does not check these situations for backwards compatibility.

You can also use an object option to configure this rule for each type of syntax.
Each of the following options can be set to `"never"`, `"always"`, `"always-multiline"`, `"only-multiline"`, or `"ignore"`.
The default for each option is `"never"` unless otherwise specified.
@@ -68,8 +66,8 @@ The default for each option is `"never"` unless otherwise specified.
* `objects` is for object literals and object patterns of destructuring. (e.g. `let {a,} = {a: 1};`)
* `imports` is for import declarations of ES Modules. (e.g. `import {a,} from "foo";`)
* `exports` is for export declarations of ES Modules. (e.g. `export {a,};`)
* `functions` is for function declarations and function calls. (e.g. `(function(a,){ })(b,);`)<br>
`functions` is set to `"ignore"` by default for consistency with the string option.
* `functions` is for function declarations and function calls. (e.g. `(function(a,){ })(b,);`)
* `functions` should only be enabled when linting ECMAScript 2017 or higher.

### never

@@ -1,6 +1,6 @@
# Enforces spacing around commas (comma-spacing)

Spacing around commas improve readability of a list of items. Although most of the style guidelines for languages prescribe adding a space after a comma and not before it, it is subjective to the preferences of a project.
Spacing around commas improves readability of a list of items. Although most of the style guidelines for languages prescribe adding a space after a comma and not before it, it is subjective to the preferences of a project.

```js
var foo = 1, bar = 2;
@@ -124,6 +124,6 @@ If your project will not be following a consistent comma-spacing pattern, turn t
* [space-in-brackets](space-in-brackets.md) (deprecated)
* [space-in-parens](space-in-parens.md)
* [space-infix-ops](space-infix-ops.md)
* [space-after-keywords](space-after-keywords)
* [space-unary-ops](space-unary-ops)
* [space-return-throw-case](space-return-throw-case)
* [space-after-keywords](space-after-keywords.md)
* [space-unary-ops](space-unary-ops.md)
* [space-return-throw-case](space-return-throw-case.md)
@@ -37,8 +37,9 @@ This rule also accepts an additional `exceptions` object:
* `"ObjectExpression": true` ignores comma style in object literals
* `"ObjectPattern": true` ignores comma style in object patterns of destructuring
* `"VariableDeclaration": true` ignores comma style in variable declarations
* `"NewExpression": true` ignores comma style in the parameters of constructor expressions

A way to determine the node types as defined by [ESTree](https://github.com/estree/estree) is to use the [online demo](http://eslint.org/parser).
A way to determine the node types as defined by [ESTree](https://github.com/estree/estree) is to use the [online demo](https://eslint.org/parser).

### last

@@ -70,13 +70,18 @@ If you can't determine an appropriate complexity limit for your code, then it's

## Further Reading

* [About Complexity](http://jscomplexity.org/complexity)
* [Complexity Analysis of JavaScript Code](http://ariya.ofilabs.com/2012/12/complexity-analysis-of-javascript-code.html)
* [Cyclomatic Complexity](https://en.wikipedia.org/wiki/Cyclomatic_complexity)
* [Complexity Analysis of JavaScript Code](https://ariya.io/2012/12/complexity-analysis-of-javascript-code)
* [More about Complexity in JavaScript](https://craftsmanshipforsoftware.com/2015/05/25/complexity-for-javascript/)
* [About Complexity](https://web.archive.org/web/20160808115119/http://jscomplexity.org/complexity)
* [Discussion about Complexity in ESLint and more links](https://github.com/eslint/eslint/issues/4808#issuecomment-167795140)

## Related Rules

* [max-depth](max-depth.md)
* [max-len](max-len.md)
* [max-lines](max-lines.md)
* [max-lines-per-function](max-lines-per-function.md)
* [max-nested-callbacks](max-nested-callbacks.md)
* [max-params](max-params.md)
* [max-statements](max-statements.md)
@@ -25,11 +25,17 @@ This rule does not apply to brackets that are separated from the adjacent value

## Options

This rule has a string option:
This rule has two options, a string option and an object option.

String option:

* `"never"` (default) disallows spaces inside computed property brackets
* `"always"` requires one or more spaces inside computed property brackets

Object option:

* `"enforceForClassMembers": true` additionally applies this rule to class members (default is `false`)

### never

Examples of **incorrect** code for this rule with the default `"never"` option:
@@ -84,6 +90,53 @@ var x = {[ b ]: a}
obj[ foo[ bar ] ]
```

#### enforceForClassMembers

By default, this rule does not check class declarations and class expressions,
as the default value for `enforceForClassMembers` is `false`.

When `enforceForClassMembers` is set to `true`, the rule will also disallow/enforce spaces inside of
computed keys of class methods, getters and setters.

Examples of **incorrect** code for this rule with `"never"` and `{ "enforceForClassMembers": true }`:

```js
/*eslint computed-property-spacing: ["error", "never", { "enforceForClassMembers": true }]*/
/*eslint-env es6*/
class Foo {
[a ]() {}
get [b ]() {}
set [b ](value) {}
}
const Bar = class {
[ a](){}
static [ b]() {}
static get [ c ]() {}
static set [ c ](value) {}
}
```

Examples of **correct** code for this rule with `"never"` and `{ "enforceForClassMembers": true }`:

```js
/*eslint computed-property-spacing: ["error", "never", { "enforceForClassMembers": true }]*/
/*eslint-env es6*/
class Foo {
[a]() {}
get [b]() {}
set [b](value) {}
}
const Bar = class {
[a](){}
static [b]() {}
static get [c]() {}
static set [c](value) {}
}
```

## When Not To Use It

@@ -2,7 +2,7 @@

Constructors of derived classes must call `super()`.
Constructors of non derived classes must not call `super()`.
If this is not observed, the javascript engine will raise a runtime error.
If this is not observed, the JavaScript engine will raise a runtime error.

This rule checks whether or not there is a valid `super()` call.

@@ -0,0 +1,35 @@
# enforce default parameters to be last (default-param-last)

Putting default parameter at last allows function calls to omit optional tail arguments.

```js
// Correct: optional argument can be omitted
function createUser(id, isAdmin = false) {}
createUser("tabby")
// Incorrect: optional argument can **not** be omitted
function createUser(isAdmin = false, id) {}
createUser(undefined, "tabby")
```

## Rule Details

This rule enforces default parameters to be the last of parameters.

Examples of **incorrect** code for this rule:

```js
/* eslint default-param-last: ["error"] */
function f(a = 0, b) {}
function f(a, b = 0, c) {}
```

Examples of **correct** code for this rule:

```js
/* eslint default-param-last: ["error"] */
function f(a, b = 0) {}
```
@@ -20,7 +20,7 @@ This rule aims to enforce newline consistency in member expressions. This rule p

The rule takes one option, a string:

* If it is `"object"`, the dot in a member expression should be on the same line as the object portion. The default is `"object"`.
* If it is `"object"` (default), the dot in a member expression should be on the same line as the object portion.
* If it is `"property"`, the dot in a member expression should be on the same line as the property portion.

### object
@@ -43,7 +43,13 @@ Examples of **correct** code for the default `"object"` option:
var foo = object.
property;
var bar = object.property;
var bar = (
object
).
property;
var baz = object.property;
```

### property
@@ -48,7 +48,7 @@ var x = foo["class"]; // Property name is a reserved word, square-bracket notati

### allowPattern

For example, when preparing data to be sent to an external API, it is often required to use property names that include underscores. If the `camelcase` rule is in effect, these [snake case](http://en.wikipedia.org/wiki/Snake_case) properties would not be allowed. By providing an `allowPattern` to the `dot-notation` rule, these snake case properties can be accessed with bracket notation.
For example, when preparing data to be sent to an external API, it is often required to use property names that include underscores. If the `camelcase` rule is in effect, these [snake case](https://en.wikipedia.org/wiki/Snake_case) properties would not be allowed. By providing an `allowPattern` to the `dot-notation` rule, these snake case properties can be accessed with bracket notation.

Examples of **correct** code for the sample `{ "allowPattern": "^[a-z]+(_[a-z]+)+$" }` option:

@@ -10,7 +10,7 @@ This rule enforces at least one newline (or absence thereof) at the end
of non-empty files.

Prior to v0.16.0 this rule also enforced that there was only a single line at
the end of the file. If you still want this behaviour, consider enabling
the end of the file. If you still want this behavior, consider enabling
[no-multiple-empty-lines](no-multiple-empty-lines.md) with `maxEOF` and/or
[no-trailing-spaces](no-trailing-spaces.md).

@@ -2,7 +2,7 @@

It is considered good practice to use the type-safe equality operators `===` and `!==` instead of their regular counterparts `==` and `!=`.

The reason for this is that `==` and `!=` do type coercion which follows the rather obscure [Abstract Equality Comparison Algorithm](http://www.ecma-international.org/ecma-262/5.1/#sec-11.9.3).
The reason for this is that `==` and `!=` do type coercion which follows the rather obscure [Abstract Equality Comparison Algorithm](https://www.ecma-international.org/ecma-262/5.1/#sec-11.9.3).
For instance, the following statements are all considered `true`:

* `[] == false`
@@ -114,7 +114,7 @@ foo == null

### allow-null

**Deprecated:** Instead of using this option use "always" and pass a "null" option property with value "ignore". This will tell eslint to always enforce strict equality except when comparing with the `null` literal.
**Deprecated:** Instead of using this option use "always" and pass a "null" option property with value "ignore". This will tell ESLint to always enforce strict equality except when comparing with the `null` literal.

```js
["error", "always", {"null": "ignore"}]
@@ -0,0 +1,24 @@
# Enforce "for" loop update clause moving the counter in the right direction. (for-direction)

## Rule Details

A `for` loop with a stop condition that can never be reached, such as one with a counter that moves in the wrong direction, will run infinitely. While there are occasions when an infinite loop is intended, the convention is to construct such loops as `while` loops. More typically, an infinite for loop is a bug.

Examples of **incorrect** code for this rule:

```js
/*eslint for-direction: "error"*/
for (var i = 0; i < 10; i--) {
}
for (var i = 10; i >= 0; i++) {
}
```

Examples of **correct** code for this rule:

```js
/*eslint for-direction: "error"*/
for (var i = 0; i < 10; i++) {
}
```
@@ -101,5 +101,5 @@ This rule can safely be turned off if your project does not care about enforcing

## Compatibility

- **JSCS**: [disallowSpacesInCallExpression](http://jscs.info/rule/disallowSpacesInCallExpression)
- **JSCS**: [requireSpacesInCallExpression](http://jscs.info/rule/requireSpacesInCallExpression)
- **JSCS**: [disallowSpacesInCallExpression](https://jscs-dev.github.io/rule/disallowSpacesInCallExpression)
- **JSCS**: [requireSpacesInCallExpression](https://jscs-dev.github.io/rule/requireSpacesInCallExpression)
@@ -4,10 +4,6 @@

This rule requires function names to match the name of the variable or property to which they are assigned. The rule will ignore property assignments where the property name is a literal that is not a valid identifier in the ECMAScript version specified in your configuration (default ES5).

## Options

This rule takes an optional string of "always" or "never" (when omitted, it defaults to "always"), and an optional options object with one key, `includeCommonJSModuleExports`, and a boolean value. This option defaults to `false`, which means that `module.exports` and `module["exports"]` are ignored by this rule. If `includeCommonJSModuleExports` is set to true, `module.exports` and `module["exports"]` will be checked by this rule.

Examples of **incorrect** code for this rule:

```js
@@ -21,14 +17,6 @@ var obj = {foo: function bar() {}};
({['foo']: function bar() {}});
```

```js
/*eslint func-name-matching: ["error", { "includeCommonJSModuleExports": true }]*/
/*eslint func-name-matching: ["error", "always", { "includeCommonJSModuleExports": true }]*/ // these are equivalent
module.exports = function foo(name) {};
module['exports'] = function foo(name) {};
```

```js
/*eslint func-name-matching: ["error", "never"] */
@@ -97,10 +85,56 @@ module.exports = function foo(name) {};
module['exports'] = function foo(name) {};
```

## Options

This rule takes an optional string of "always" or "never" (when omitted, it defaults to "always"), and an optional options object with two properties `considerPropertyDescriptor` and `includeCommonJSModuleExports`.

### considerPropertyDescriptor

A boolean value that defaults to `false`. If `considerPropertyDescriptor` is set to true, the check will take into account the use of `Object.create`, `Object.defineProperty`, `Object.defineProperties`, and `Reflect.defineProperty`.

Examples of **correct** code for the `{ considerPropertyDescriptor: true }` option:

```js
/*eslint func-name-matching: ["error", { "considerPropertyDescriptor": true }]*/
/*eslint func-name-matching: ["error", "always", { "considerPropertyDescriptor": true }]*/ // these are equivalent
var obj = {};
Object.create(obj, {foo:{value: function foo() {}}});
Object.defineProperty(obj, 'bar', {value: function bar() {}});
Object.defineProperties(obj, {baz:{value: function baz() {} }});
Reflect.defineProperty(obj, 'foo', {value: function foo() {}});
```

Examples of **incorrect** code for the `{ considerPropertyDescriptor: true }` option:

```js
/*eslint func-name-matching: ["error", { "considerPropertyDescriptor": true }]*/
/*eslint func-name-matching: ["error", "always", { "considerPropertyDescriptor": true }]*/ // these are equivalent
var obj = {};
Object.create(obj, {foo:{value: function bar() {}}});
Object.defineProperty(obj, 'bar', {value: function baz() {}});
Object.defineProperties(obj, {baz:{value: function foo() {} }});
Reflect.defineProperty(obj, 'foo', {value: function value() {}});
```

### includeCommonJSModuleExports

A boolean value that defaults to `false`. If `includeCommonJSModuleExports` is set to true, `module.exports` and `module["exports"]` will be checked by this rule.

Examples of **incorrect** code for the `{ includeCommonJSModuleExports: true }` option:

```js
/*eslint func-name-matching: ["error", { "includeCommonJSModuleExports": true }]*/
/*eslint func-name-matching: ["error", "always", { "includeCommonJSModuleExports": true }]*/ // these are equivalent
module.exports = function foo(name) {};
module['exports'] = function foo(name) {};
```

## When Not To Use It

Do not use this rule if you want to allow named functions to have different names from the variable or property to which they are assigned.

## Compatibility

* **JSCS**: [requireMatchingFunctionName](http://jscs.info/rule/requireMatchingFunctionName)
* **JSCS**: [requireMatchingFunctionName](https://jscs-dev.github.io/rule/requireMatchingFunctionName)
@@ -20,6 +20,15 @@ This rule has a string option:
* `"as-needed"` requires function expressions to have a name, if the name cannot be assigned automatically in an ES6 environment
* `"never"` disallows named function expressions, except in recursive functions, where a name is needed

This rule has an object option:

* `"generators": "always" | "as-needed" | "never"`
* `"always"` require named generators
* `"as-needed"` require named generators if the name cannot be assigned automatically in an ES6 environment.
* `"never"` disallow named generators where possible.

When a value for `generators` is not provided the behavior for generator functions falls back to the base option.

### always

Examples of **incorrect** code for this rule with the default `"always"` option:
@@ -29,6 +38,10 @@ Examples of **incorrect** code for this rule with the default `"always"` option:
Foo.prototype.bar = function() {};
const cat = {
meow: function() {}
}
(function() {
// ...
}())
@@ -41,6 +54,10 @@ Examples of **correct** code for this rule with the default `"always"` option:
Foo.prototype.bar = function bar() {};
const cat = {
meow() {}
}
(function bar() {
// ...
}())
@@ -50,7 +67,7 @@ Foo.prototype.bar = function bar() {};

ECMAScript 6 introduced a `name` property on all functions. The value of `name` is determined by evaluating the code around the function to see if a name can be inferred. For example, a function assigned to a variable will automatically have a `name` property equal to the name of the variable. The value of `name` is then used in stack traces for easier debugging.

Examples of **incorrect** code for this rule with the default `"as-needed"` option:
Examples of **incorrect** code for this rule with the `"as-needed"` option:

```js
/*eslint func-names: ["error", "as-needed"]*/
@@ -62,13 +79,17 @@ Foo.prototype.bar = function() {};
}())
```

Examples of **correct** code for this rule with the default `"as-needed"` option:
Examples of **correct** code for this rule with the `"as-needed"` option:

```js
/*eslint func-names: ["error", "as-needed"]*/
var bar = function() {};
const cat = {
meow: function() {}
}
(function bar() {
// ...
}())
@@ -100,12 +121,80 @@ Foo.prototype.bar = function() {};
}())
```

### generators

Examples of **incorrect** code for this rule with the `"always", { "generators": "as-needed" }` options:

```js
/*eslint func-names: ["error", "always", { "generators": "as-needed" }]*/
(function*() {
// ...
}())
```

Examples of **correct** code for this rule with the `"always", { "generators": "as-needed" }` options:

```js
/*eslint func-names: ["error", "always", { "generators": "as-needed" }]*/
var foo = function*() {};
```

Examples of **incorrect** code for this rule with the `"always", { "generators": "never" }` options:

```js
/*eslint func-names: ["error", "always", { "generators": "never" }]*/
var foo = bar(function *baz() {});
```

Examples of **correct** code for this rule with the `"always", { "generators": "never" }` options:

```js
/*eslint func-names: ["error", "always", { "generators": "never" }]*/
var foo = bar(function *() {});
```

Examples of **incorrect** code for this rule with the `"as-needed", { "generators": "never" }` options:

```js
/*eslint func-names: ["error", "as-needed", { "generators": "never" }]*/
var foo = bar(function *baz() {});
```

Examples of **correct** code for this rule with the `"as-needed", { "generators": "never" }` options:

```js
/*eslint func-names: ["error", "as-needed", { "generators": "never" }]*/
var foo = bar(function *() {});
```

Examples of **incorrect** code for this rule with the `"never", { "generators": "always" }` options:

```js
/*eslint func-names: ["error", "never", { "generators": "always" }]*/
var foo = bar(function *() {});
```

Examples of **correct** code for this rule with the `"never", { "generators": "always" }` options:

```js
/*eslint func-names: ["error", "never", { "generators": "always" }]*/
var foo = bar(function *baz() {});
```

## Further Reading

* [Functions Explained](http://markdaggett.com/blog/2013/02/15/functions-explained/)
* [Function Names in ES6](http://www.2ality.com/2015/09/function-names-es6.html)
* [Function Names in ES6](http://2ality.com/2015/09/function-names-es6.html)

## Compatibility

* **JSCS**: [requireAnonymousFunctions](http://jscs.info/rule/requireAnonymousFunctions)
* **JSCS**: [disallowAnonymousFunctions](http://jscs.info/rule/disallowAnonymousFunctions)
* **JSCS**: [requireAnonymousFunctions](https://jscs-dev.github.io/rule/requireAnonymousFunctions)
* **JSCS**: [disallowAnonymousFunctions](https://jscs-dev.github.io/rule/disallowAnonymousFunctions)
@@ -55,7 +55,7 @@ This rule has a string option:

This rule has an object option for an exception:

* `"allowArrowFunctions": true` (default `false`) allows the use of arrow functions
* `"allowArrowFunctions": true` (default `false`) allows the use of arrow functions (honoured only when using `declaration`)

### expression

@@ -0,0 +1,202 @@
# enforce line breaks between arguments of a function call (function-call-argument-newline)

A number of style guides require or disallow line breaks between arguments of a function call.

## Rule Details

This rule enforces line breaks between arguments of a function call.

## Options

This rule has a string option:

* `"always"` (default) requires line breaks between arguments
* `"never"` disallows line breaks between arguments
* `"consistent"` requires consistent usage of line breaks between arguments


### always

Examples of **incorrect** code for this rule with the default `"always"` option:

```js
/*eslint function-call-argument-newline: ["error", "always"]*/
foo("one", "two", "three");
bar("one", "two", {
one: 1,
two: 2
});
baz("one", "two", (x) => {
console.log(x);
});
```

Examples of **correct** code for this rule with the default `"always"` option:

```js
/*eslint function-call-argument-newline: ["error", "always"]*/
foo(
"one",
"two",
"three"
);
bar(
"one",
"two",
{ one: 1, two: 2 }
);
// or
bar(
"one",
"two",
{
one: 1,
two: 2
}
);
baz(
"one",
"two",
(x) => {
console.log(x);
}
);
```


### never

Examples of **incorrect** code for this rule with the default `"never"` option:

```js
/*eslint function-call-argument-newline: ["error", "never"]*/
foo(
"one",
"two", "three"
);
bar(
"one",
"two", {
one: 1,
two: 2
}
);
baz(
"one",
"two", (x) => {
console.log(x);
}
);
```

Examples of **correct** code for this rule with the `"never"` option:

```js
/*eslint function-call-argument-newline: ["error", "never"]*/
foo("one", "two", "three");
// or
foo(
"one", "two", "three"
);
bar("one", "two", { one: 1, two: 2 });
// or
bar("one", "two", {
one: 1,
two: 2
});
baz("one", "two", (x) => {
console.log(x);
});
```

### consistent

Examples of **incorrect** code for this rule with the default `"consistent"` option:

```js
/*eslint function-call-argument-newline: ["error", "consistent"]*/
foo("one", "two",
"three");
//or
foo("one",
"two", "three");
bar("one", "two",
{ one: 1, two: 2}
);
baz("one", "two",
(x) => { console.log(x); }
);
```

Examples of **correct** code for this rule with the default `"consistent"` option:

```js
/*eslint function-call-argument-newline: ["error", "consistent"]*/
foo("one", "two", "three");
// or
foo(
"one",
"two",
"three"
);
bar("one", "two", {
one: 1,
two: 2
});
// or
bar(
"one",
"two",
{ one: 1, two: 2 }
);
// or
bar(
"one",
"two",
{
one: 1,
two: 2
}
);
baz("one", "two", (x) => {
console.log(x);
});
// or
baz(
"one",
"two",
(x) => {
console.log(x);
}
);
```


## When Not To Use It

If you don't want to enforce line breaks between arguments, don't enable this rule.

## Related Rules

* [function-paren-newline](function-paren-newline.md)
* [func-call-spacing](func-call-spacing.md)
* [object-property-newline](object-property-newline.md)
* [array-element-newline](array-element-newline.md)
@@ -0,0 +1,328 @@
# enforce consistent line breaks inside function parentheses (function-paren-newline)

Many style guides require or disallow newlines inside of function parentheses.

## Rule Details

This rule enforces consistent line breaks inside parentheses of function parameters or arguments.

### Options

This rule has a single option, which can either be a string or an object.

* `"always"` requires line breaks inside all function parentheses.
* `"never"` disallows line breaks inside all function parentheses.
* `"multiline"` (default) requires linebreaks inside function parentheses if any of the parameters/arguments have a line break between them. Otherwise, it disallows linebreaks.
* `"multiline-arguments"` works like `multiline` but allows linebreaks inside function parentheses if there is only one parameter/argument.
* `"consistent"` requires consistent usage of linebreaks for each pair of parentheses. It reports an error if one parenthesis in the pair has a linebreak inside it and the other parenthesis does not.
* `{ "minItems": value }` requires linebreaks inside function parentheses if the number of parameters/arguments is at least `value`. Otherwise, it disallows linebreaks.

Example configurations:

```json
{
"rules": {
"function-paren-newline": ["error", "never"]
}
}
```

```json
{
"rules": {
"function-paren-newline": ["error", { "minItems": 3 }]
}
}
```

Examples of **incorrect** code for this rule with the `"always"` option:

```js
/* eslint function-paren-newline: ["error", "always"] */
function foo(bar, baz) {}
var foo = function(bar, baz) {};
var foo = (bar, baz) => {};
foo(bar, baz);
```

Examples of **correct** code for this rule with the `"always"` option:

```js
/* eslint function-paren-newline: ["error", "always"] */
function foo(
bar,
baz
) {}
var foo = function(
bar, baz
) {};
var foo = (
bar,
baz
) => {};
foo(
bar,
baz
);
```

Examples of **incorrect** code for this rule with the `"never"` option:

```js
/* eslint function-paren-newline: ["error", "never"] */
function foo(
bar,
baz
) {}
var foo = function(
bar, baz
) {};
var foo = (
bar,
baz
) => {};
foo(
bar,
baz
);
```

Examples of **correct** code for this rule with the `"never"` option:

```js
/* eslint function-paren-newline: ["error", "never"] */
function foo(bar, baz) {}
function foo(bar,
baz) {}
var foo = function(bar, baz) {};
var foo = (bar, baz) => {};
foo(bar, baz);
foo(bar,
baz);
```

Examples of **incorrect** code for this rule with the default `"multiline"` option:

```js
/* eslint function-paren-newline: ["error", "multiline"] */
function foo(bar,
baz
) {}
var foo = function(
bar, baz
) {};
var foo = (
bar,
baz) => {};
foo(bar,
baz);
foo(
function() {
return baz;
}
);
```

Examples of **correct** code for this rule with the default `"multiline"` option:

```js
/* eslint function-paren-newline: ["error", "multiline"] */
function foo(bar, baz) {}
var foo = function(
bar,
baz
) {};
var foo = (bar, baz) => {};
foo(bar, baz, qux);
foo(
bar,
baz,
qux
);
foo(function() {
return baz;
});
```

Examples of **incorrect** code for this rule with the `"consistent"` option:

```js
/* eslint function-paren-newline: ["error", "consistent"] */
function foo(bar,
baz
) {}
var foo = function(bar,
baz
) {};
var foo = (
bar,
baz) => {};
foo(
bar,
baz);
foo(
function() {
return baz;
});
```

Examples of **correct** code for this rule with the `"consistent"` option:

```js
/* eslint function-paren-newline: ["error", "consistent"] */
function foo(bar,
baz) {}
var foo = function(bar, baz) {};
var foo = (
bar,
baz
) => {};
foo(
bar, baz
);
foo(
function() {
return baz;
}
);
```

Examples of **incorrect** code for this rule with the `"multiline-arguments"` option:

```js
/* eslint function-paren-newline: ["error", "multiline-arguments"] */
function foo(bar,
baz
) {}
var foo = function(bar,
baz
) {};
var foo = (
bar,
baz) => {};
foo(
bar,
baz);
foo(
bar, qux,
baz
);
```

Examples of **correct** code for this rule with the consistent `"multiline-arguments"` option:

```js
/* eslint function-paren-newline: ["error", "multiline-arguments"] */
function foo(
bar,
baz
) {}
var foo = function(bar, baz) {};
var foo = (
bar
) => {};
foo(
function() {
return baz;
}
);
```

Examples of **incorrect** code for this rule with the `{ "minItems": 3 }` option:

```js
/* eslint function-paren-newline: ["error", { "minItems": 3 }] */
function foo(
bar,
baz
) {}
function foo(bar, baz, qux) {}
var foo = function(
bar, baz
) {};
var foo = (bar,
baz) => {};
foo(bar,
baz);
```

Examples of **correct** code for this rule with the `{ "minItems": 3 }` option:

```js
/* eslint function-paren-newline: ["error", { "minItems": 3 }] */
function foo(bar, baz) {}
var foo = function(
bar,
baz,
qux
) {};
var foo = (
bar, baz, qux
) => {};
foo(bar, baz);
foo(
bar, baz, qux
);
```

## When Not To Use It

If don't want to enforce consistent linebreaks inside function parentheses, do not turn on this rule.
@@ -75,6 +75,27 @@ An example of shorthand configuration:
"generator-star-spacing": ["error", "after"]
```

Additionally, this rule allows further configurability via overrides per function type.

* `named` provides overrides for named functions
* `anonymous` provides overrides for anonymous functions
* `method` provides overrides for class methods or property function shorthand

An example of a configuration with overrides:

```json
"generator-star-spacing": ["error", {
"before": false,
"after": true,
"anonymous": "neither",
"method": {"before": true, "after": true}
}]
```

In the example configuration above, the top level "before" and "after" options define the default behavior of
the rule, while the "anonymous" and "method" options override the default behavior.
Overrides can be either an object with "before" and "after", or a shorthand string as above.

## Examples

### before
@@ -137,10 +158,50 @@ var anonymous = function*() {};
var shorthand = { *generator() {} };
```

Examples of **incorrect** code for this rule with overrides present:

```js
/*eslint generator-star-spacing: ["error", {
"before": false,
"after": true,
"anonymous": "neither",
"method": {"before": true, "after": true}
}]*/
/*eslint-env es6*/
function * generator() {}
var anonymous = function* () {};
var shorthand = { *generator() {} };
class Class { static* method() {} }
```

Examples of **correct** code for this rule with overrides present:

```js
/*eslint generator-star-spacing: ["error", {
"before": false,
"after": true,
"anonymous": "neither",
"method": {"before": true, "after": true}
}]*/
/*eslint-env es6*/
function* generator() {}
var anonymous = function*() {};
var shorthand = { * generator() {} };
class Class { static * method() {} }
```

## When Not To Use It

If your project will not be using generators or you are not concerned with spacing consistency, you do not need this rule.

## Further Reading

* [Understanding ES6: Generators](https://leanpub.com/understandinges6/read/#leanpub-auto-generators)
* [Understanding ES6: Generators](https://leanpub.com/understandinges6/read/#leanpub-auto-generators)
@@ -0,0 +1,97 @@
# Enforces that a return statement is present in property getters (getter-return)

The get syntax binds an object property to a function that will be called when that property is looked up. It was first introduced in ECMAScript 5:

```js
var p = {
get name(){
return "nicholas";
}
};
Object.defineProperty(p, "age", {
get: function (){
return 17;
}
});
```

Note that every `getter` is expected to return a value.

## Rule Details

This rule enforces that a return statement is present in property getters.

Examples of **incorrect** code for this rule:

```js
/*eslint getter-return: "error"*/
p = {
get name(){
// no returns.
}
};
Object.defineProperty(p, "age", {
get: function (){
// no returns.
}
});
class P{
get name(){
// no returns.
}
}
```

Examples of **correct** code for this rule:

```js
/*eslint getter-return: "error"*/
p = {
get name(){
return "nicholas";
}
};
Object.defineProperty(p, "age", {
get: function (){
return 18;
}
});
class P{
get name(){
return "nicholas";
}
}
```

## Options

This rule has an object option:

* `"allowImplicit": false` (default) disallows implicitly returning `undefined` with a `return` statement.

Examples of **correct** code for the `{ "allowImplicit": true }` option:

```js
/*eslint getter-return: ["error", { allowImplicit: true }]*/
p = {
get name(){
return; // return undefined implicitly.
}
};
```

## When Not To Use It

If your project will not be using ES5 property getters you do not need this rule.

## Further Reading

* [MDN: Functions getter](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/get)
* [Understanding ES6: Accessor Properties](https://leanpub.com/understandinges6/read/#leanpub-auto-accessor-properties)
@@ -33,6 +33,9 @@ for (key in foo) {
if (Object.prototype.hasOwnProperty.call(foo, key)) {
doSomething(key);
}
}
for (key in foo) {
if ({}.hasOwnProperty.call(foo, key)) {
doSomething(key);
}
@@ -45,5 +48,5 @@ for (key in foo) {

## Further Reading

* [Exploring JavaScript for-in loops](http://javascriptweblog.wordpress.com/2011/01/04/exploring-javascript-for-in-loops/)
* [The pitfalls of using objects as maps in JavaScript](http://www.2ality.com/2012/01/objects-as-maps.html)
* [Exploring JavaScript for-in loops](https://javascriptweblog.wordpress.com/2011/01/04/exploring-javascript-for-in-loops/)
* [The pitfalls of using objects as maps in JavaScript](http://2ality.com/2012/01/objects-as-maps.html)
@@ -78,4 +78,4 @@ confident that some other form of monitoring will help you catch the problem.
## Further Reading

* [The Art Of Node: Callbacks](https://github.com/maxogden/art-of-node#callbacks)
* [Nodejitsu: What are the error conventions?](http://docs.nodejitsu.com/articles/errors/what-are-the-error-conventions)
* [Nodejitsu: What are the error conventions?](https://docs.nodejitsu.com/articles/errors/what-are-the-error-conventions/)
@@ -34,7 +34,7 @@ function foo(...x) { }
var { x } = {};
var { x: a} = {};
var { a: [x]} = {};
({ prop: obj.x }) = {};
({ prop: obj.x } = {});
```

Examples of **correct** code for this rule with the default options:
@@ -62,7 +62,7 @@ function foo(...args) { }
var { prop } = {};
var { prop: a } = {};
var { prop: [x] } = {};
({ prop: obj.longName }) = {};
({ prop: obj.longName } = {});
var data = { "x": 1 }; // excused because of quotes
data["y"] = 3; // excused because of calculated property access
```
@@ -72,12 +72,12 @@ This rule has a shorthand integer option for the `"min"` object property.
Examples of **incorrect** code for this rule with a minimum of 4:

```js
/*eslint id-length: ["error", 4]*/
/*eslint id-length: ["error", { "min": 4 }]*/
/*eslint-env es6*/
var val = 5;
obj.e = document.body;
function (e) { };
function foo (e) { };
try {
dangerousStuff();
} catch (e) {
@@ -91,13 +91,13 @@ function foo(...x) { }
var { x } = {};
var { x: a} = {};
var { a: [x]} = {};
({ prop: obj.x }) = {};
({ prop: obj.x } = {});
```

Examples of **correct** code for this rule with a minimum of 4:

```js
/*eslint id-length: ["error", 4]*/
/*eslint id-length: ["error", { "min": 4 }]*/
/*eslint-env es6*/
var value = 5;
@@ -118,7 +118,7 @@ function foobar(...args) { }
var { prop } = {};
var { prop: a } = {};
var { prop: [x] } = {};
({ prop: obj.name }) = {};
({ prop: obj.name } = {});
var data = { "x": 1 }; // excused because of quotes
data["y"] = 3; // excused because of calculated property access
```
@@ -141,7 +141,7 @@ Examples of **incorrect** code for this rule with the `{ "min": 4 }` option:
var val = 5;
obj.e = document.body;
function (e) { };
function foo (e) { };
try {
dangerousStuff();
} catch (e) {
@@ -155,7 +155,7 @@ function foo(...x) { }
var { x } = {};
var { x: a} = {};
var { a: [x]} = {};
({ prop: obj.x }) = {};
({ prop: obj.x } = {});
```

Examples of **correct** code for this rule with the `{ "min": 4 }` option:
@@ -182,7 +182,7 @@ function foobar(...args) { }
var { prop } = {};
var { prop: a } = {};
var { prop: [x] } = {};
({ prop: obj.name }) = {};
({ prop: obj.name } = {});
var data = { "x": 1 }; // excused because of quotes
data["y"] = 3; // excused because of calculated property access
```
@@ -192,7 +192,7 @@ data["y"] = 3; // excused because of calculated property access
Examples of **incorrect** code for this rule with the `{ "max": 10 }` option:

```js
/*eslint id-length: ["error", { "max": "10" }]*/
/*eslint id-length: ["error", { "max": 10 }]*/
/*eslint-env es6*/
var reallyLongVarName = 5;
@@ -210,7 +210,7 @@ try {
Examples of **correct** code for this rule with the `{ "max": 10 }` option:

```js
/*eslint id-length: ["error", { "max": "10" }]*/
/*eslint id-length: ["error", { "max": 10 }]*/
/*eslint-env es6*/
var varName = 5;
@@ -234,8 +234,8 @@ Examples of **correct** code for this rule with the `{ "properties": "never" }`
/*eslint-env es6*/
var myObj = { a: 1 };
({ a: obj.x.y.z }) = {};
({ prop: obj.i }) = {};
({ a: obj.x.y.z } = {});
({ prop: obj.i } = {});
```

### exceptions