Support an "eslint" property for package.json configuration

[milesj]

What is the purpose of this pull request? (put an "X" next to item)

[x] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[x] Add something to the core
[ ] Other, please explain:

What changes did you make? (Give an overview)

Support eslint alongside eslintConfig as a configuration property in package.json.

A large majority of build tools that allow configuration through package.json simply use the project name as the property name, like babel, ava, jest, instead of babelConfig, etc.

This PR simply adds a bit of consistency with other build tools, and removes any confusion when eslint is used (instead of eslintConfig).

Is there anything you'd like reviewers to focus on?

Not really. Consumer choice is always nice.

[jsf-clabot]

All committers have signed the CLA.

[eslintbot]

Thanks for the pull request, @milesj! I took a look to make sure it's ready for merging and found some changes are needed:

• The commit summary needs to begin with a tag (such as Fix: or Update:). Please check out our guide for how to properly format your commit summary and update it on this pull request.

Can you please update the pull request to address these?

(More information can be found in our pull request guide.)

[mention-bot]

@milesj, thanks for your PR! By analyzing the history of the files in this pull request, we identified @nzakas, @mysticatea and @not-an-aardvark to be potential reviewers.

[eslintbot]

LGTM

[not-an-aardvark]

Thanks for the pull request. However, this same idea was suggested in #2670, #5735, and #7800, and was rejected in each case because the team found that it could be confusing and unnecessary to have two ways of doing the same thing.

[milesj]

It looks to be brought up enough to be reconsidered.

There's nothing inherently wrong in support multiple options.

[platinumazure]

My take: Setting up lint configuration (as least the basic structure) only has to happen once, so with typing eslintConfig instead of eslint that should only happen once per project. Given how infrequently the user is inconvenienced by this, I don't think it's worth the extra maintenance burden. So I agree with previous decisions.

[kaicataldo]

I like the idea of standardizing configuration in the JS ecosystem, but I agree that it's confusing to support multiple options.

[not-an-aardvark]

If we're adding an eslintIgnore property for package.json in #8458, it might also be confusing to have properties called eslint and eslintIgnore.

[not-an-aardvark]

Thanks for your interest in improving ESLint. Unfortunately, it looks like this issue didn't get enough support from the team and so I'm closing it. 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 consensus after a long time tend to never do it, and as such, we close those issues. This doesn't mean the idea isn't interesting, just that it's not something the team can commit to.