Allow config extends from actual package-name/path, without mandatory eslint-config or @scope/eslint-config prefix

The version of ESLint you are using. >=6

The problem you want to solve.

I know the problem has already been mentioned twice here, here and also here for plugins but time has passed and I am opening this issue to reconsider the problem in light of an always more modern and integrated ESLint.

Naming things is hard, and having the eslint-config prefix surely helps discoverability. But having tooling configuration all over the place is not beneficial from the developer experience perspective.

My use case here would be to have my organisation various configuration in one package and be able to simply npm install my-org-config and set my various tooling configuration in one place (package.json):

{
  "prettier": "my-org-config/prettier",
  "eslint": {
    "extends": "my-org-config/eslint"
  },
  "stylelint": {
    "extends": "my-org-config/stylelint"
  }
}

I am currently not able to do this for ESLint as either eslint-config or @my-org/eslint-config are required for it to pick up the configuration. Prettier and stylelint allow it.

Your take on the correct solution to problem.

Extends should function more like a require.resolve and don’t make naming rules mandatory. It could still try to resolve “eslint-config-” as fallback to keep consistency, I don’t see any problem with that.

Are you willing to submit a pull request to implement this change?

Yes although some work seem to have been already started in this PR here from @edahlseng

[nzakas]

Thanks for the suggestion. We recently decided to do a complete overhaul of the config system (see the RFC: https://github.com/eslint/rfcs/pull/9), so we aren’t going to be making further changes to the way eslintrc configs are handled.

In the new system, you’ll be able to programmatically load configs from wherever you want.

[nzakas]

This RFC was open for over a year before being accepted: https://github.com/eslint/rfcs/pull/9

It had numerous revisions, was posted on Twitter, and many comments on what would and wouldn’t work. There are links to relevant issues and history of problems in the RFC. I’d suggest reading through that to answer the questions you may have about complexities and motivation.

While I understand that you do not agree with the decision, there was ample opportunity for community input before this decision was made.

As mentioned before, we won’t be making any further changes to the existing config system, so I’m closing this issue.