Fallback to no prefix when searching for eslint-config modules

[edahlseng]

Currently ESLint only supports extending from configurations that are prefixed with eslint-config-. Some people may store their shared ESLint configurations in a module that has other uses as well, however (such as a module that contains multiple configurations, such as ESLint configuration, stylelint configuration, etc.). In these situations, it doesn't make sense for the module to be prefixed with eslint-config- .

I propose that when reading the extends portion of a configuration, ESLint first checks for modules prefixed with eslint-config-, and then if that fails, it continues checking for modules without the prefix.

Tell us about your environment

• ESLint Version: 4.19.1
• Node Version: 8.10.0
• npm Version: 5.7.1

What parser (default, Babel-ESLint, etc.) are you using?
Babel-ESLint

Please show your full configuration:

{
  "extends": "@edahlseng/linter-configuration"
}

What did you do? Please include the actual source code causing the issue, as well as the command that you used to run ESLint.
I tried to extend configuration from a module that isn't named with a eslint-config- prefix.

What did you expect to happen?
I expected ESLint to check for a package prefixed by eslint-config- and then, if that failed, search for the exact package name.

What actually happened? Please include the actual, raw output from ESLint.
ESLint failed to find the module, with the following error: Cannot find module '@edahlseng/eslint-config-linter-configuration'.

[platinumazure]

Hi @edahlseng, thanks for the issue!

I'm wondering if we had historical reasons for not supporting this in the past. Depending on what those might be, we can see if those are still valid and then see if this should be changed.

[edahlseng]

Hi @platinumazure, it looks like this issue was brought up about a year ago in #8644, and was closed simply due to not enough support. To address that, I'm happy to spearhead the dev efforts needed to make this happen (and submitted PR #10133 as a possible solution).

[edahlseng]

@platinumazure what's the latest status on this issue?

[ilyavolodin]

I'm not sure I'm sold on this change. What's the problem with prefixing the packages with the specified that clearly describes what the package does? Original thinking behind prefixes was to avoid naming collision as well as increase findability and clarity.

[edahlseng]

@ilyavolodin problems arise when people don't package ESLint configurations in a package all of its own. I've run into this recently where the team that I was working with packaged all of our linting configurations into one package, and so it didn't make sense to prefix the package with the name eslint-config since it wasn't just ESLint related.

[eslint-deprecated]

Unfortunately, it looks like there wasn't enough interest from the team
or community to implement this change. 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 accepted status after 21 days tend to
never be accepted, and as such, we close those issues.
This doesn't mean the idea isn't interesting or useful, just that it's
not something the team can commit to.

Thanks for contributing to ESLint and we appreciate your understanding.