Validate options passed to CLIEngine API

[edmorley]

Tell us about your environment

• ESLint Version: 4.19.1
• Node Version: 9.11.1
• npm Version: N/A (yarn)

What parser (default, Babel-ESLint, etc.) are you using?
babel-eslint

Please show your full configuration:

See below.

What did you do? Please include the actual source code causing the issue, as well as the command that you used to run ESLint.

Used CLIEngine like so:

const { CLIEngine } = require('eslint');

const cli = new CLIEngine({
  cwd: "...",
  root: true,
  useEslintrc: false,
  failOnError: true,
  extensions: ["js", "jsx"],
  baseConfig: { extends: ["airbnb"] },
  plugins: ["babel", "react"],
  envs: ["es6", "browser", "commonjs"],
  parser: "babel-eslint",
  parserOptions: {
    ecmaVersion: 2017,
    sourceType: "module",
    ecmaFeatures: {
      objectLiteralDuplicateProperties: false,
      generators: true,
      impliedStrict: true
    }
  },
  settings: {
    react: {
      pragma: "h"
    }
  }
});

const report = cli.executeOnFiles(['src/']);

What did you expect to happen?

For the invalid CLIEngine option settings to trigger a schema validation error, like happens which an invalid option is found in an .eslintrc.js when using the CLI:

Error: ESLint configuration in ...\.eslintrc.js is invalid:
        - Unexpected top-level property "thisOptionIsNotValid".

What actually happened? Please include the actual, raw output from ESLint.

The CLIEngine command silently ignores the invalid option, causing confusion - since I instead thought eslint-plugin-react was at fault.

If there was a schema validation warning, I would have known sooner to search for how to pass options like settings when using CLIEngine (ie using baseConfig instead). It seems that this has tripped up a few other people too - eg #7247, #4402 (and I'm presuming more for other differences between the CLI and CLIEngine).

If it's too expensive/unwanted to add a schema validation check to CLIEngine (eg because the CLI does its own, and so pointless to do a second, if the CLI uses CLIEngine too) - then perhaps there can be a second schema validation method (for the CLIEngine options instead) that consumers of the API can call first if desired?

Many thanks :-)

[platinumazure]

I think this could be a good idea, although it's a breaking change.

[edmorley]

I think this could be a good idea, although it's a breaking change.

Would adding initially as just a warning be considered breaking?

[eslint-deprecated]

Unfortunately, it looks like there wasn't enough interest from the team
or community to implement this change. While we wish we'd be able to
accommodate everyone's requests, we do need to prioritize. We've found
that issues failing to reach accepted status after 21 days tend to
never be accepted, and as such, we close those issues.
This doesn't mean the idea isn't interesting or useful, just that it's
not something the team can commit to.

Thanks for contributing to ESLint and we appreciate your understanding.

[edmorley]

Please can this be reopened for further discussion? :-)

[platinumazure]

Thanks @edmorley, I'll reopen.

[kaicataldo]

@platinumazure It looks like you've assigned this to yourself. Are you still championing this change? If so, should it go through the RFC process that we have that in place?

[btmills]

For the v7.0.0 release, we're focusing on implementing RFC40 and the new ESLint class, so we decided in today's TSC meeting not to include this in v7.0.0. If there's still interest in doing this, we can consider it for the v8.0.0 release.

[btmills]

We incorporated more validations into the new ESLint API, including warning about extra unknown options. The CLIEngine is now deprecated, so we can close this as fixed in the new API!