Proposal: validate eslintrc's properties

Tell us about your environment

• ESLint Version: 3.17.1
• Node Version: 7.2.0
• npm Version: 3.10.9

Please show your full configuration:

module.exports = {
	ecmaVersion: 2017
};

Current behavior

ESLint ignores properties it doesn’t understand

Suggested behavior

ESLint cli prints a notice about the invalid eslintrc

y tho

The config above looks fine, the property name is correct but its position is wrong. It should be like this:

module.exports = {
	parserOptions: {
		ecmaVersion: 2017
	}
};

I was wondering why ESLint wasn’t recognizing my async/await and --debug didn’t mention anything wrong with the config 😦

This didn’t help either, it looked like it was correctly picked up:

$ eslint --print-config index.js
{
  "globals": {},
  "env": {},
  "rules": {},
  "parserOptions": {},
  "ecmaVersion": 2017
}

[not-an-aardvark]

@btmills That sounds like a good idea and is worth further discussion. For the purposes of this issue, though, it seems orthogonal to the question of whether ESLint should validate espree’s config (since we can always add a way for parsers to opt-in to schema validation later). For now, I think we should go with the following:

• Validate top-level properties
• Do not validate espree’s options from eslint
• Maybe validate espree’s options from espree, at runtime

There are a few reasons I’m opposed to adding a special case to validate parserOptions when the default parser is used:

• It couples eslint and espree together. The two projects are maintained by the same team, but they’re different projects. Having to update a schema update in eslint whenever we add an option to espree seems like it would be a code smell, and it would also prevent people from using new espree options until we released a new version of eslint with a schema to allow those options.
• It adds a capability to the default parser that isn’t possible for any other parsers. This seems like it would go against eslint’s “everything-is-pluggable” philosophy.

[btmills]

Instead of doing their own error handling, what if parsers could optionally supply a schema for their options?