Eslint keeps requiring overridden parsers when extending config

[kirill-konshin]

This is a follow up for autoclosed issue #11240

Can be reproduced here https://github.com/aladdin-add/eslint-issue-11240

I am using plugin:typescript/recommended (eslint-plugin-typescript) on top of react-app (eslint-config-react-app) and as I can see from eslint --print-config the parser field is overwritten from babel-eslint to correct /Users/dis/Sites/apple-music/node_modules/eslint-plugin-typescript/parser.js, but for some reason ESLint still tries to resolve the unneeded parser, which is not even in final config.

I'm kinda okay to still install the useless parser, but it is a bit annoying.

Tell us about your environment

• ESLint Version: 5.8.0

Please show your full configuration:

Configuration

{
  "extends": [
    "eslint:recommended",
    "react-app",
    "plugin:typescript/recommended",
    "plugin:import/recommended",
    "plugin:jsx-a11y/recommended",
    "plugin:prettier/recommended"
  ],
  "rules": {
    "no-console": "off",
    "prettier/prettier": "error"
  },
  "env": {
    "browser": true,
    "mocha": true,
    "node": true
  },
  "settings": {
    "import/resolver": {
      "node": {
        "extensions": [
          ".js",
          ".jsx",
          ".ts",
          ".tsx"
        ]
      }
    }
  }
}

eslint --fix src/**/*.ts src/**/*.tsx

What actually happened? Please include the actual, raw output from ESLint.

Error: Cannot find module 'babel-eslint'
Referenced from: /Users/dis/Sites/apple-music/.eslintrc
    at ModuleResolver.resolve (/Users/dis/Sites/apple-music/node_modules/eslint/lib/util/module-resolver.js:72:19)
    at loadFromDisk (/Users/dis/Sites/apple-music/node_modules/eslint/lib/config/config-file.js:514:42)
    at load (/Users/dis/Sites/apple-music/node_modules/eslint/lib/config/config-file.js:564:20)
    at configExtends.reduceRight (/Users/dis/Sites/apple-music/node_modules/eslint/lib/config/config-file.js:430:36)
    at Array.reduceRight (<anonymous>)
    at applyExtends (/Users/dis/Sites/apple-music/node_modules/eslint/lib/config/config-file.js:408:26)
    at loadFromDisk (/Users/dis/Sites/apple-music/node_modules/eslint/lib/config/config-file.js:528:22)
    at load (/Users/dis/Sites/apple-music/node_modules/eslint/lib/config/config-file.js:564:20)
    at configExtends.reduceRight (/Users/dis/Sites/apple-music/node_modules/eslint/lib/config/config-file.js:430:36)
    at Array.reduceRight (<anonymous>)

[not-an-aardvark]

Hi, thanks for opening an issue.

As I mentioned in #11240, I don't think this is a bug. ESLint does config validation at each step of the process, so it validates the contents of intermediate configs even if the contents don't appear in the final resolved config. If a shareable config references a parser that doesn't exist, that shareable config is invalid.

[kirill-konshin]

I agree and disagree at the same time. I agree that it does make sense to verify each config to make clear which one produces the issue. At the same time, it does not make sense to actually require anything, especially if it will be overwritten. It is a waste of resources at least.

In my opinion it should be an effort from both sides: fix the require at ESLint side and fix the improper config from CRA side.

I have created an issue for create-react-app facebook/create-react-app#6129 but it is stale.

[nzakas]

The problem from ESLint's point of view is that we cannot know whether or not a parser will end up in the final config. A new config is calculated for every file that ESLint lints, so we need to keep each config in memory and know that each config in memory is valid so we can quickly merge them multiple times.

Plus, we need to have some idea at which level the parser is being required from in order to resolve it correctly.

While this does seem annoying in your specific case, I think overall ESLint is doing the right thing.

[kirill-konshin]

Agree. Both on validation and require path.

But. CRA is fairly popular product, so anyone who use their config is prone to the above mentioned issue, and, unfortunately, CRA turnaround is slow...

So looks like for now there's no way other than to drag all of it's deps...

[nzakas]

@kirill-konshin yeah, I'm sorry we couldn't be of more help. This sounds like something you should work through with the CRA team, as this behavior has been in ESLint for quite some time.