feat(config-file): add alternative property name for config

[Scrum]

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

[x] Add something to the core

What changes did you make? (Give an overview)

Add alternative property name for config in package.json. - eslint
Now you can use eslint in package.json to configure.

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

Nothing in particular.

[jsf-clabot]

All committers have signed the CLA.

[eslintbot]

Thanks for the pull request, @gitscrum! 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]

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

[platinumazure]

@gitscrum Thanks for the pull request.

Can you please explain what problem this is solving?

[Scrum]

@platinumazure Hi

Can you please explain what problem this is solving?

I'm creating collector configurations and see some tacit agreement in such packages as babel, ava, stylelint, eslint all have roughly similar structure configuration { ...options, plugins: {...}, extends: {} }, babel { ...options, plugins: {...}, extends: {...}, presets: {...} }.

The naming of the packages is almost identical with the semantic logic configuration babel-plugin-array-includes, babel-preset-babili where babel is the package name matches the name in the configuration.

"devDependencies": {
  "babel-plugin-array-includes": "^2.0.3",
  "babel-preset-babili": "0.0.9"
},
"babel": {
  "preset": [ ... ],
  "plugins": [ ... ]
}

Based on this understanding I want in the future to create some guidelines for choosing the package names and create Linter ))

[nzakas]

This was brought up a while ago and we decided not to make such a change. Discussion: #2670

I don't see a good reason to revisit that decision.

[Scrum]

What for you is good for others may be unacceptable.
Explain why eslintConfig ? There are some reasons why you that critical ?

[nzakas]

@gitscrum all we are talking about is what the key of a JSON structure is, I'm not sure how such a decision could be considered unacceptable. I already linked to the previous discussion, but just to be clear: we've had this for a long time and there's no good reason to change it. Personal preference is not a good reason to either break existing users or introduce a second way of doing the same thing.

I'm sorry that you disagree, however, I don't see any reason to revisit this decision. We have a lot of existing users we need to think about.

[Scrum]

@nzakas

we've had this for a long time and there's no good reason to change it.

The base was provided above, as I wrote, I create a collector configuration which is based on [name-pkg]-[type/method]-[name]. But I didn't change but only provided an alternative method

Personal preference is not a good reason

Personal preference is when one person changes something for their inner/hidden project. In this case, we have more than one and my goal is open and described above.

we've had this for a long time.

Do not think this argument why are you using eslintConfig and why it is critical for you.

I'm not sure how such a decision could be considered unacceptable.

Do you think that adding alternative methods and giving in fact a single method will allow you to
understand it ? Are you serious ?

I'm sorry that you disagree, however, I don't see any reason to revisit this decision.

Don't be sorry, I did everything possible to improve your very best package, only your horizon is used to determine the future for this.