Should the `useEslintrc` option be documented? #338

If that works it’s a bug. We don’t intend to support that option and it might cause other unforeseen issues. We should prevent its usage.

from my perspective, reasons i like this option:

1. i can use a dot-js file for (i.e. .eslintrc.js) which i find cleaner to work with than json (i.e. package.json), in terms of less double-quotes, commentability, etc.
2. a .eslintrc file positions for portability (historically, i have had to temporarily eject from xo because of transient issues)
3. it aligns with the prettier strategy which honors .prettierrc config and then falls back to settings in package.json

but, just so i understand your position, you were thinking that xo would ignore any kind of .eslintrc config, and xo users would be required to disperse config that could otherwise go there into an eslintConfig section or in an xo[.rules] section in package.json...?

i can use a dot-js file for (i.e. .eslintrc.js) which i find cleaner to work with than json (i.e. package.json), in terms of less double-quotes, commentability, etc.

We plan to support that by using cosmiconfig. See: https://github.com/xojs/xo/pull/279#issuecomment-407250935

but, just so i understand your position, you were thinking that xo would ignore any kind of .eslintrc config, and xo users would be required to disperse config that could otherwise go there into an eslintConfig section or in an xo[.rules] section in package.json...?

Yes. XO needs full control of how you define rules as we do a lot extra stuff with them. We could support .eslintrc (we won't though), but that would need to be an actual XO option and not something that is just accidentally passed through to ESLint.

thanks sindre,

i think i'm with ya, so:

• this proposal would allow, for instance, a .xo.js file to be found at the root of the project with stuff like?:

{
  parser: 'babel-eslint',
  env: ['browser'],
  rules: {
    'capitalized-comments': 0,
    'react/prop-types': 0,
    'no-unused-expressions': 0,
    'prefer-rest-params': 0
  }
}

• is there a pass-thru for parserOptions like these, or are they supposed to be derived?:

{
  parserOptions: {
    sourceType: 'module',
    ecmaFeatures: {
      jsx: true,
      experimentalObjectRestSpread: true
    }
  }
}

best, tony.

@issuehunt has funded $40.00 to this issue.

• Submit pull request via IssueHunt to receive this reward.
• Want to contribute? Chip in to this issue via IssueHunt.
• Checkout the IssueHunt Issue Explorer to see more funded issues.
• Need help from developers? Add your repository on IssueHunt to raise funds.

@sindresorhus has rewarded $36.00 to @richienb. See it on IssueHunt

• :moneybag: Total deposit: $40.00
• :tada: Repository reward(0%): $0.00
• :wrench: Service fee(10%): $4.00