Autogenerated new docs and demo at Sat Dec 23 2017 17:58:36

_posts/2017-12-23-eslint-v4.14.0-released.md

@@ -0,0 +1,75 @@
+---
+layout: post
+title: ESLint v4.14.0 released
+tags:
+  - release
+  - minor
+---
+# ESLint v4.14.0 released
+
+We just pushed ESLint v4.14.0, which is a minor release upgrade of ESLint. This release adds some new features and fixes several bugs found in the previous release. 
+
+
+
+
+
+
+## Features
+
+
+* [ae51eb2](https://github.com/eslint/eslint/commit/ae51eb2) New: Add allowImplicit option to [array-callback-return](/docs/rules/array-callback-return) (fixes [#8539](https://github.com/eslint/eslint/issues/8539)) ([#9344](https://github.com/eslint/eslint/issues/9344)) (James C. Davis)
+
+
+
+
+## Enhancements
+
+
+* [be2f57e](https://github.com/eslint/eslint/commit/be2f57e) Update: support separate requires in [one-var](/docs/rules/one-var). (fixes [#6175](https://github.com/eslint/eslint/issues/6175)) ([#9441](https://github.com/eslint/eslint/issues/9441)) (薛定谔的猫)
+* [75c7419](https://github.com/eslint/eslint/commit/75c7419) Update: Logical-and is counted in [`complexity`](/docs/rules/complexity) rule (fixes [#8535](https://github.com/eslint/eslint/issues/8535)) ([#9754](https://github.com/eslint/eslint/issues/9754)) (Kevin Partington)
+* [1c2aafd](https://github.com/eslint/eslint/commit/1c2aafd) Update: Improve parser integrations (fixes [#8392](https://github.com/eslint/eslint/issues/8392)) ([#8755](https://github.com/eslint/eslint/issues/8755)) (Toru Nagashima)
+
+
+
+
+## Bug Fixes
+
+
+* [43d4ba8](https://github.com/eslint/eslint/commit/43d4ba8) Fix: false positive on rule[`lines-between-class-members`](/docs/rules/lines-between-class-members) (fixes [#9665](https://github.com/eslint/eslint/issues/9665)) ([#9680](https://github.com/eslint/eslint/issues/9680)) (sakabar)
+
+
+
+
+## Documentation
+
+
+* [370d614](https://github.com/eslint/eslint/commit/370d614) Docs: Fix typos ([#9751](https://github.com/eslint/eslint/issues/9751)) (Jed Fox)
+* [eb4b1e0](https://github.com/eslint/eslint/commit/eb4b1e0) Docs: reintroduce misspelling in [`valid-typeof`](/docs/rules/valid-typeof) example ([#9753](https://github.com/eslint/eslint/issues/9753)) (Teddy Katz)
+* [e9d5dfd](https://github.com/eslint/eslint/commit/e9d5dfd) Docs: improve [no-extra-parens](/docs/rules/no-extra-parens) formatting ([#9747](https://github.com/eslint/eslint/issues/9747)) (Rich Trott)
+* [f252c19](https://github.com/eslint/eslint/commit/f252c19) Docs: Make the lint message `source` property a little more subtle ([#9735](https://github.com/eslint/eslint/issues/9735)) (Jed Fox)
+* [5a5c23c](https://github.com/eslint/eslint/commit/5a5c23c) Docs: fix the link to contributing page ([#9727](https://github.com/eslint/eslint/issues/9727)) (Victor Hom)
+* [f44ce11](https://github.com/eslint/eslint/commit/f44ce11) Docs: change beginner to good first issue label text ([#9726](https://github.com/eslint/eslint/issues/9726)) (Victor Hom)
+* [f819920](https://github.com/eslint/eslint/commit/f819920) Docs: fix typos ([#9723](https://github.com/eslint/eslint/issues/9723)) (Thomas Broadley)
+
+
+
+
+## Dependency Upgrades
+
+
+* [4ddc131](https://github.com/eslint/eslint/commit/4ddc131) Upgrade: debug@^3.1.0 ([#9731](https://github.com/eslint/eslint/issues/9731)) (Kevin Partington)
+
+
+
+
+
+
+## Chores
+
+
+* [8196c45](https://github.com/eslint/eslint/commit/8196c45) Chore: Reorganize CLI options and associated docs ([#9758](https://github.com/eslint/eslint/issues/9758)) (Kevin Partington)
+* [37d066c](https://github.com/eslint/eslint/commit/37d066c) Chore: Add unit tests for overrides glob matching. ([#9744](https://github.com/eslint/eslint/issues/9744)) (Robert Jackson)
+* [805a94e](https://github.com/eslint/eslint/commit/805a94e) Chore: Fix typo in CLIEngine test name ([#9741](https://github.com/eslint/eslint/issues/9741)) (@scriptdaemon)
+* [14baa2e](https://github.com/eslint/eslint/commit/14baa2e) Chore: improve [arrow-body-style](/docs/rules/arrow-body-style) error message (refs [#5498](https://github.com/eslint/eslint/issues/5498)) ([#9718](https://github.com/eslint/eslint/issues/9718)) (Teddy Katz)
+
+

docs/developer-guide/contributing/working-on-issues.md

@@ -13,7 +13,7 @@ Our public [issues tracker](https://github.com/eslint/eslint/issues) lists all o
 
 We use labels to indicate the status of issues. The most complete documentation on the labels is found in the [Maintainer Guide](https://eslint.org/docs/maintainer-guide/issues.html#when-an-issue-is-opened), but most contributors should find the information on this page sufficient. The most important questions that labels can help you, as a contributor, answer are:
 
-1. Is this issue available for me to work on? If you have little or no experience contributing to ESLint, the [`beginner`](https://github.com/eslint/eslint/labels/beginner) label marks appropriate issues. Otherwise, the [`help wanted`](https://github.com/eslint/eslint/labels/help%20wanted) label is an invitation to work on the issue. If you have more experience, you can try working on other issues labeled [`accepted`](https://github.com/eslint/eslint/labels/accepted). Conversely, issues not yet ready to work on are labeled `triage`, `evaluating`, and/or `needs bikeshedding`, and issues that cannot currently be worked on because of something else, such as a bug in a dependency, are labeled `blocked`.
+1. Is this issue available for me to work on? If you have little or no experience contributing to ESLint, the [`good first issue`](https://github.com/eslint/eslint/labels/good%20first%20issue) label marks appropriate issues. Otherwise, the [`help wanted`](https://github.com/eslint/eslint/labels/help%20wanted) label is an invitation to work on the issue. If you have more experience, you can try working on other issues labeled [`accepted`](https://github.com/eslint/eslint/labels/accepted). Conversely, issues not yet ready to work on are labeled `triage`, `evaluating`, and/or `needs bikeshedding`, and issues that cannot currently be worked on because of something else, such as a bug in a dependency, are labeled `blocked`.
 1. What is this issue about? Labels describing the nature of issues include `bug`, `enhancement`, `feature`, `question`, `rule`, `documentation`, `core`, `build`, `cli`, `infrastructure`, `breaking`, and `chore`. These are documented in the [Maintainer Guide](https://eslint.org/docs/maintainer-guide/issues.html#types-of-issues).
 1. What is the priority of this issue? Because we have a lot of issues, we prioritize certain issues above others. The following is the list of priorities, from highest to lowest:
 

docs/developer-guide/nodejs-api.md

@@ -133,12 +133,11 @@ The information available for each linting message is:
 * `nodeType` - the node or token type that was reported with the problem.
 * `ruleId` - the ID of the rule that triggered the messages (or null if `fatal` is true).
 * `severity` - either 1 or 2, depending on your configuration.
-* `source` - the line of code where the problem is (or empty string if it can't be found).
 * `endColumn` - the end column of the range on which the error occurred (this property is omitted if it's not range).
 * `endLine` - the end line of the range on which the error occurred (this property is omitted if it's not range).
 * `fix` - an object describing the fix for the problem (this property is omitted if no fix is available).
 
-**Please note**: the `source` property will be removed from the linting messages in an upcoming breaking release. If you depend on this property, you can still use the `getSourceCode` method described below to get the line of code for each message.
+Linting message objects have a deprecated `source` property. This property **will be removed** from linting messages in an upcoming breaking release. If you depend on this property, you should now use the `SourceCode` instance provided by the linter.
 
 You can also get an instance of the `SourceCode` object used inside of `linter` by using the `getSourceCode()` method:
 
@@ -381,7 +380,6 @@ The return value is an object containing the results of the linting operation. H
                 line: 1,
                 column: 13,
                 nodeType: "ExpressionStatement",
-                source: "\"use strict\"", // Deprecated: see "please note" paragraph below.
                 fix: { range: [12, 12], text: ";" }
             }],
             errorCount: 1,
@@ -430,7 +428,6 @@ var report = cli.executeOnFiles(["myfile.js", "lib/"]);
                     line: 1,
                     column: 13,
                     nodeType: "ExpressionStatement",
-                    source: "\"use strict\"", // Deprecated: see "please note" paragraph below.
                     fix: { range: [12, 12], text: ";" }
                 },
                 {
@@ -439,8 +436,7 @@ var report = cli.executeOnFiles(["myfile.js", "lib/"]);
                     message: "Function name `bar` should match variable name `foo`",
                     line: 2,
                     column: 5,
-                    nodeType: "VariableDeclarator",
-                    source: "var foo = function bar() {};"
+                    nodeType: "VariableDeclarator"
                 }
             ],
             errorCount: 2,
@@ -469,7 +465,6 @@ If the operation ends with a parsing error, you will get a single message for th
                     ruleId: null,
                     fatal: true,
                     severity: 2,
-                    source: "fucntion foo() {}",
                     message: "Parsing error: Unexpected token foo",
                     line: 1,
                     column: 10
@@ -499,7 +494,7 @@ The top-level report object has a `results` array containing all linting results
 
 The top-level report object also has `errorCount` and `warningCount` which give the exact number of errors and warnings respectively on all the files.
 
-**Please note**: the `source` property will be removed from the linting messages returned in `messages` in an upcoming breaking release. If you depend on this property, you should now use the top-level `source` or `output` properties instead.
+Report message objects have a deprecated `source` property. This property **will be removed** from the linting messages returned in `messages` in an upcoming breaking release. If you depend on this property, you should now use the top-level `source` or `output` properties instead.
 
 Once you get a report object, it's up to you to determine how to output the results. Fixes will not be automatically applied to the files, even if you set `fix: true` when constructing the `CLIEngine` instance. To apply fixes to the files, call [`outputFixes`](#outputfixes).
 
@@ -846,4 +841,4 @@ ruleTester.run("my-rule", myRule, {
 ## Deprecated APIs
 
 * `cli` - the `cli` object has been deprecated in favor of `CLIEngine`. As of v1.0.0, `cli` is no longer exported and should not be used by external tools.
-* `linter` - the `linter` object has has been deprecated in favor of `Linter`, as of v4.0.0
+* `linter` - the `linter` object has been deprecated in favor of `Linter` as of v4.0.0.