Repository: create-react-app
Issue: ESLint config not picked up by eslint-config-react-app unless it's JSON (other ESLint config methods not picked up)
Labels: issue: proposal,needs triage

### Is your proposal related to a problem?

<!--
  Provide a clear and concise description of what the problem is.
  For example, "I'm always frustrated when..."
-->

I've been wondering about this for a while why, and finally figured out what's going on. We explicitly allow `no-console` (i.e. we want to _allow_ console logging). Since updating our ESLint config with `'no-console': 'off',` everything has worked fine _when we run ESLint directly_. However, when we `npm start` and ESLint is run by webpack, it was still spewing console logging warnings all over the place. This was baffling.

Then I looked at this page: [https://www.npmjs.com/package/eslint-config-react-app](https://www.npmjs.com/package/eslint-config-react-app) and it says, in part (emphasis mine):

> Then create a file named **.eslintrc.json** with following contents in the root folder of your project:
> `{  "extends": "react-app" }`
> That's it! You can override the settings from eslint-config-react-app by editing the .eslintrc.json file. Learn more about [configuring ESLint](https://eslint.org/docs/user-guide/configuring) on the ESLint website.

I looked, and we didn't have an `.eslintrc.**json**` file, we had an `.eslintrc.**js**` file. This is perfectly legal for ESLint. [This page](https://eslint.org/docs/latest/user-guide/configuring/) says:

> Configuration Files - use a JavaScript, JSON, or YAML file to specify configuration information for an entire directory and all of its subdirectories. This can be in the form of a [.eslintrc.*](https://eslint.org/docs/latest/user-guide/configuring/configuration-files#configuration-file-formats) file or an eslintConfig field in a [package.json](https://docs.npmjs.com/files/package.json) file, both of which ESLint will look for and read automatically, or you can specify a configuration file on the [command line](https://eslint.org/docs/latest/user-guide/command-line-interface).

and then the linked [Configuration File Formats](https://eslint.org/docs/latest/user-guide/configuring/configuration-files#configuration-file-formats) list says: 

> ESLint supports configuration files in several formats:
> - JavaScript - use .eslintrc.js and export an object containing your configuration.
> - JavaScript (ESM) - use .eslintrc.cjs when running ESLint in JavaScript packages that specify "type":"module" in their package.json. Note that ESLint does not support ESM configuration at this time.
> - YAML - use .eslintrc.yaml or .eslintrc.yml to define the configuration structure.
> - JSON - use .eslintrc.json to define the configuration structure. ESLint’s JSON files also allow JavaScript-style comments.
> - package.json - create an eslintConfig property in your package.json file and define your configuration there.

And `.eslintrc.json` actually is the second-lowest priority among them, coming only before `package.json`.

When I reformatted our `.eslintrc.js` file into an equivalent `.eslintrc.json` file, the issue went away, which strongly suggests that eslint-config-react-app is neither delegating resolution nor replicating the rules used by ESLint itself for finding configurations. 

### Describe the solution you'd like

I would like for these scripts to either delegate the resolution of config information to ESLint itself, or if that's not possible (as I suspect it's not, if eslint-config-react-app wants to provide configuration of its own) I would like these scripts to "hunt" for config by replicating the rules used by ESLint itself for finding configurations.

### Describe alternatives you've considered

I reformatted our `.eslintrc.js` file into an equivalent `.eslintrc.json` file, and the issue went away, so we could bend to you, and probably will, until this issue is resolved. It's annoying though because in the `.js` format, we can have things like comments, whereas we cannot in `.json`. This is useful for temporarily commenting out a rule, or for leaving an explanation of why we set a rule the way we did.

### Additional context

I don't think I have anything more to add.