Validate options passed to CLIEngine API

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 😃

[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!