I think create-react-app's confusing-browser-globals is a cool idea, will xo consider apply it?

I have a block of code which uses str.replace(/=*$/, '') to on a base64 string (round trip is not needed or wanted, I'm just generating random strings). First no-div-regex complained about this, then I updated the code to str.replace(/\=*$/, '') and no-useless-escape complained instead.

If you want I can open a bug with eslint, see if they'll add a ignore-div-regex boolean option to no-useless-escape. For now I'm just disabling no-div-regex on my own repo, leaving it to editors to disambiguate with regex syntax highlighting.

See here:
https://github.com/sindresorhus/eslint-config-xo/blob/master/index.js#L118

What is the reason for it being restricted?

In https://github.com/sindresorhus/eslint-config-xo/blob/master/index.js#L105
you mention issue was closed.

Do you reactive the strict rule ?

Unless I'm mistaken, it seems to me that the settings under xo./config/plugins.js are not included here.

E.g. all the rules related to the eslint-plugin-import` plugin.

Why is that, I would thought that these rules are quite useful?

I'm actually using XO but in some case (lack of editor integration) I need to revert to using ESLint directly with 'eslint-plugin-xo,eslint-config-xo` etc.

eslint/eslint@eb1ef88

The capitalized-comments rule is currently configured as such

      "capitalized-comments": ["error", "always", {
        "ignorePattern": "pragma|ignore",
        "ignoreInlineComments": true,
        "ignoreConsecutiveComments": true
      }]

This ends up forcing the // prettier-ignore comment to be // Prettier-ignore which leads to prettier not ignoring the next line.

https://www.npmjs.com/package/eslint-config-xo is 0.15.4
https://github.com/sindresorhus/eslint-config-xo/blob/master/package.json is 0.15.2

babel-eslint has been deprecated, in favor of @babel/eslint, that is hosted in Babel monorepo. To get recent updates XO config should use the new package

First of all thanks for this nice configuration i really love it :) !

I need to customize few rules and it works great except one : no-unused-vars.
In your configuration you set it to : 'no-unused-vars': 2.

In my tests i used should like this :

import shouldHttp from 'should-http';

describe('...', () => {
   it('...', done => {
      request.get('...', (err, res, body) => {
         res.should.have.status(200);
         done();
      });
   });
});
...

eslint think that i do not use shouldHttp.

I customized xo rules in package.json (according to http://eslint.org/docs/rules/no-unused-vars.html) with this rule : "no-unused-vars": [2, {"args": "after-used", "argsIgnorePattern": "shouldHttp"}] and i also tried "no-unused-vars": [2, {"args": "all", "argsIgnorePattern": "shouldHttp"}] but nothing worked i had to make this :

import shouldHttp from 'should-http'; // eslint-disable-line

Maybe it's not a problem with xo but eslint ? (or me ...)

I upgraded to 0.16.0 and started to get the following errorL

xo:
Configuration for rule "valid-typeof" is invalid:
Value "[object Object]" has more items than allowed.

Not sure if it is related to 0.16.0 or to new eslint (3.6.1) released two days ago...

I'd like to request that 'avoidEscape: true' be added to the default options for the quotes rule. Prior to ea693f3 I just used backticks in cases where the string contained single-quotes, but now const value = 'single-quote \' must be escaped';.

CC @sindresorhus

Edit: I'm willing to post a PR for this if acceptable.

import(
  /* webpackChunkName: "my-chunk-name" */ './some-chunk' // Error: Comments should not begin with a lowercase character
);

https://webpack.js.org/api/module-methods/#magic-comments

Preview

After upgrade eslint-config-xo from 0.22.2 to 0.23.0, I get this error:

> xo
Error: /home/travis/build/fanfoujs/fandou/node_modules/eslint-config-xo/index.js:
	Configuration for rule "array-element-newline" is invalid:
	Value "consistent" should be equal to one of the allowed values.
	Value "consistent" should be object.
	Value "consistent" should match exactly one schema in oneOf.
Referenced from: /home/travis/build/fanfoujs/fandou/node_modules/eslint-config-xo/esnext.js
Referenced from: 
    at validateRuleOptions (/home/travis/build/fanfoujs/fandou/node_modules/eslint/lib/config/config-validator.js:119:19)
    at Object.keys.forEach.id (/home/travis/build/fanfoujs/fandou/node_modules/eslint/lib/config/config-validator.js:162:9)
    at Array.forEach (<anonymous>)
    at validateRules (/home/travis/build/fanfoujs/fandou/node_modules/eslint/lib/config/config-validator.js:161:30)
    at Object.validate (/home/travis/build/fanfoujs/fandou/node_modules/eslint/lib/config/config-validator.js:239:5)
    at loadFromDisk (/home/travis/build/fanfoujs/fandou/node_modules/eslint/lib/config/config-file.js:516:19)
    at load (/home/travis/build/fanfoujs/fandou/node_modules/eslint/lib/config/config-file.js:559:20)
    at configExtends.reduceRight (/home/travis/build/fanfoujs/fandou/node_modules/eslint/lib/config/config-file.js:425:36)
    at Array.reduceRight (<anonymous>)
    at applyExtends (/home/travis/build/fanfoujs/fandou/node_modules/eslint/lib/config/config-file.js:403:26)
npm ERR! Test failed.  See above for more details.

You may check the CI logs here: https://travis-ci.org/fanfoujs/fandou/jobs/412029424.

How to reproduce

$ git clone [email protected]:fanfoujs/fandou.git -b greenkeeper/eslint-config-xo-0.23.0
$ cd fandou
$ npm i
$ npm test

I'm curious that why I got this error. I reviewed the commit history of eslint-config-xo, but there is no notable changes.

The rule is quite configurable, so I don't have time right now to decide on all the options.

http://eslint.org/docs/rules/padding-line-between-statements

Suggestions welcome.

The new config now sets the default for ecma6. For projects that still want to use ecma5, this means that 'const' and other restricted keywords no longer throw parsing errors.

Is setting parserOptions.ecmaVersion to 6 required?

Added by 56a33c6

Will close
- [ #13 (bump minor version) ]
- [ #14 (bump patch version) ]

Blocker for google/eslint-config-google#6 (ESLint 2.x support for eslint-config-google)

When linting the following code:

const sortObject = require("sort-obj")
const numberSort = require("num-sort")

sortObject({ c: 2, b: 3, a: 1 }, ([_a, a], [_b, b]) => numberSort.descending(a, b))

XO throws these errors:

 test.js:10:40
  ×  10:40  _a is defined but never used. Allowed unused args must match /^_$/u.  no-unused-vars
  ×  10:49  _b is defined but never used. Allowed unused args must match /^_$/u.  no-unused-vars

However, when renaming both variables to _:

 test.js:10:48
  ×  10:48  Parsing error: Argument name clash

This is a catch-22.

// @sindresorhus

Is there a reason why the ESLint rule require-await is not included but rules like no-await-in-loop or no-return-await are?

How can I integrates XO with code analysis tools like CodeClimate or Codacy, based that these tools use the .eslintrc to parse your analysis? Any idea?

[process.exit()] doesn’t give the application any chance to respond to the error. It’s usually better to throw an error and allow the application to handle it appropriately

This sounds good, especially because most of the time throw new Error() behaves the same.
More info: http://eslint.org/docs/rules/no-process-exit

http://eslint.org/docs/rules/max-depth

I initially left it out, but might be nice to enforce less nesting.

Should we enable this or is it too opinionated? What would be a good default value?

http://eslint.org/docs/rules/complexity

I initially left it out in fear of it being too annoying, but it might be a good indicator of convoluted code. I would never want it as an error, but maybe it makes sense to add it as a warning so you know when developing locally if something is too complex? What would be a sensible default number?

http://eslint.org/docs/rules/max-lines

I'm thinking adding it as a warning.

What would be a good max? The default is 300 (excluding comments and empty lines). I think that's a good default.

// @jamestalmage @SamVerschueren @kevva

When using value == null this is reported twice by ava. This construct can be preferred for browser targets in some cases, value === null || typeof value === 'undefined' does not get minified to value == null.

Would you be willing to make eqeqeq ignore null comparisons, leave it to no-eq-null? This would make it easier to configure the exception in cases where value == null is intentional.

https://eslint.org/docs/rules/eqeqeq#options

I checked git blame, it was set to never since first commit, should we consider use trailing comma?

I'd recommend use "always-multiline".

http://eslint.org/docs/rules/max-params

I think it makes sense. If you have more than a few arguments you should probably convert them to an object anyways.

What should be max? 3 or 4?

Finally I'm trying to start to use XO (nice job) and one thing that I've noticed as missing is enforcing the consistent-return rule
http://eslint.org/docs/rules/consistent-return

What do you think about adding it?

http://eslint.org/docs/rules/global-require.html
What do you think about this rule ?

I have created an ESLint utility module that I thought you might find useful.

The module is called eslint-index and you can read the full documentation on npm.

eslint-index provides a great deal of functionality including:

• List all available rules declared by ESLint and any plugins you have included
• Colour code rules depending on their status:
  • omitted (not declared anywhere in you ESLint config file)
  • 0|off (declared, but set to 0|off)
  • 1|warn
  • 2|error
• Display links to the rule documentation page next to each rule
• Filter/reject rules by their status and/or their group
  • status is as described above (omitted|off|warn|error)
  • group is eslint for the core ESLint rules or the name of any of your plugins like react|import|flowtype
• Format the output as a number or a table to get an overview of your rule settings
• Rules that have been marked as deprecated are removed from all outputs
• All of the above filters and formatting can be combined, for example:
  • filter omitted and off rules, output them as a list and display the rule doc links alongside
  • filter eslint rules and display the rule setting counters in a table

I wrote this plugin to aid the development of my own ESLint config settings and found it incredibly useful for keeping track of everything. I hope you find this module useful and please do let me know if you have any ideas on how to improve it.

I've started using class properties in some of my browser code. xo is complaining about code such as the following:

class MyClass {
  x = 1;
  y = 1;
  z = 1;

  sum() {
    return x + y + z;
  }
}

IMO the above example code is exactly correct, no line feed between class field declarations but a linefeed before the sum() function. Unfortunately it is not possible to exactly enforce this per eslint/eslint#11153. As a work-around I'm enabling exceptAfterSingleLine for my own projects. This allows multiple fields to be declared without a line-feed between each, but unfortunately does not enforce having a line-feed between the fields and the first function. This change would mostly have no effect on classes that do not use class fields as xo forbids non-empty functions from being single line.

Would you accept a patch enabling this option for the default xo config?

VSCode ESLint Plugin repeorted an error to me when using the xo config preset

Error: ESLint configuration in d:\localforagedown\node_modules\eslint-config-xo\index.js is invalid:
	- Unexpected top-level property "reportUnusedDisableDirectives".

Referenced from: d:\localforagedown\node_modules\eslint-config-xo\browser.js
Referenced from: D:\localforagedown\.eslintrc.js
    at validateConfigSchema (d:\localforagedown\node_modules\eslint\lib\config\config-validator.js:235:15)
    at Object.validate (d:\localforagedown\node_modules\eslint\lib\config\config-validator.js:261:5)
    at loadFromDisk (d:\localforagedown\node_modules\eslint\lib\config\config-file.js:544:19)
    at load (d:\localforagedown\node_modules\eslint\lib\config\config-file.js:587:20)
    at d:\localforagedown\node_modules\eslint\lib\config\config-file.js:453:36
    at Array.reduceRight (<anonymous>)
    at applyExtends (d:\localforagedown\node_modules\eslint\lib\config\config-file.js:431:26)
    at loadFromDisk (d:\localforagedown\node_modules\eslint\lib\config\config-file.js:551:22)
    at load (d:\localforagedown\node_modules\eslint\lib\config\config-file.js:587:20)
    at d:\localforagedown\node_modules\eslint\lib\config\config-file.js:453:36

https://github.com/bcoe/c8

The use of either document.getElementById("element") or document.querySelector("#element") should be consistent.

Using node 0.12.7 and npm 2.11.3, got this while installing:

npm WARN peerDependencies The peer dependency eslint@>=1.7.3 included from eslint-config-xo will no
npm WARN peerDependencies longer be automatically installed to fulfill the peerDependency 
npm WARN peerDependencies in npm 3+. Your application will need to depend on it explicitly.

Will be fixed by #11

While adding xo to my npm start script (ie "start": "xo '**/*.js' && react-scripts start"), I noticed that simple style mistakes prevent the whole project from starting. The default rules in XO should make use of both error and warn settings, reserving error only for items that are likely to cause problems (like an undefined variable) while running the code, and using warn for anything that's purely stylistic (like an incorrect number of spaces). Of course, this is sometimes a subjective distinction, but the default rules should be a reasonable attempt to distinguish the two. I shouldn't have to override half of the default rules in package.json just to be able to run xo as a part of my start scripts without breaking on minor stylistic issues that should be warnings instead of errors.

http://eslint.org/docs/rules/max-len

I know that this rule is controversial, but in most of case developpers have their IDE configured to have 2 files side by side with the max length set to 80.

Maybe 120 and configurable in the package.json with an option max-len: 80 to be less painful for common people.