You should apply parser option https://github.com/benmosher/eslint-plugin-import#importparsers

if this is not going to work, please report issue at eslint-plugin-import

Thank you for the quick response!

I'm using the following configuration along with eslint-import-resolver-typescript@1.1.1 and it doesn't work:

"settings": {
  "import/parsers": {
    "@typescript-eslint/parser": [".ts", ".tsx"]
  },
  "import/resolver": {
    "typescript": {}
  }
},

Actually, things seem to work fine when I remove the following:

"import/parsers": {
  "@typescript-eslint/parser": [".ts", ".tsx"]
},

Could the removal affect the quality of code analysis when using eslint-import-resolver-typescript?

You shouldn't need this config.
I believe eslint-plugin-import should default to the configured ESLint parser.

If a file extension is matched, the dependency parser will require and use the map key as the parser instead of the configured ESLint parser

@bradzacher Sounds great, thank you!

@kripod, @bradzacher removing

"import/resolver": {
    "typescript": {}
  }

will break imports that are defined in tsconfig#paths option. Giving the error import/no-unresolved. If you dont use that then it "fixes" the issue. But it is still a bug as I do.

I believe the intended config is:

{
  "settings": {
    "import/resolver": {
      "typescript": {}
    }
  }
}

You can remove the separate config item "import/parsers", as it will default to eslint's default parser.

@amwill04 did you find a workaround for this which also allows for a non-empty:

  "import/resolver": {
      "typescript": {}

E.g:

    "import/resolver": {
      "typescript": "./tsconfig.json"
    }

@bradzacher @kripod I would like this issue re-opened, because:
Whilst the 'intended config' given above (i.e. "typescript": {}) does work around the issue, it also prevents use of a custom tsconfig.json.

I propose that a 'real fix' would resolve the [import/named] Named type exports are not found issue regardless of what's in "import/resolver": {.

As further proof this is a bug, observe that there is no import/named error when importing:

export interface IJob {
  foo: string;
}

But importing this would cause an import/named error:

export type IJob = {
  foo: string;
}

A few things:

1

I won't be reopening this, because it clearly isn't a bug with this project.
It's an issue with a eslint-plugin-import rule, which is failing when eslint-import-resolver-typescript is configured.

2.

How come you're even using import/named?
Typescript will handle this for you automatically.

3.

Reading the documentation for the import resolver: https://github.com/alexgorbatchev/eslint-import-resolver-typescript, it looks like you've misconfigured the resolver.
The correct config is actually:

      // use <root>/path/to/folder/tsconfig.json
      "typescript": {
        "directory": "./path/to/folder"
      }

https://github.com/alexgorbatchev/eslint-import-resolver-typescript/blob/9c37a6cf1fbc2c563ca79d61523ef0affd8badd2/index.js#L34-L36

Thanks for the fast reply @bradzacher.

Good catch with 3, fixed that.

For 2 do you mean:
"why are we using import/named when TypeScript itself would fail to compile if an import is missing"?
If so then I agree! Is that something we should be disabling ourselves with overrides in .eslintrc, or should the extends listed here take care of that?

For 1 I'm happy to open an issue on https://github.com/benmosher/eslint-plugin-import, but can I just clarify what the issue is:
Are you thinking that it should be the responsibility of eslint-import-resolver-typescript to not do import/named if it sees eslint-import-resolver-typescript is configured?

Are you thinking that it should be the responsibility of eslint-import-resolver-typescript to not do import/named if it sees eslint-import-resolver-typescript is configured?

This is an inherent problem with eslint as it stands right now. In order to configure the import resolver, you have to use the "settings" field on your eslintrc. Unfortunately however - unlike with rule config, which is validated against a JSON schema, eslint provides no mechanism for defining the structure of the settings object.
Similarly, eslint-plugin-import does not provide a mechanism for defining the structure of the resolver config.

So unfortunately the whole system relies upon the users reading the documentation.

if you were to raise an issue, it would be with import-resolver-typescript - as it should probably have better validation of the configuration it's expecting.

Is that something we should be disabling ourselves with overrides in .eslintrc, or should the extends listed here take care of that?

We do not enable the rule from our plugin configs. (and we cannot, because doing so would require we have a dependency on the plugin).

Taking a guess, I think you're using the recommended config from eslint-plugin-import?
If so , then it's the former - you should disable the rule in your eslintrc.

Thanks for taking the time to write such a comprehensive reply @bradzacher 😄
We've got it all working now, we disabled the rule as you suggested.

use eslint-import-resolver-ts. https://github.com/rx-ts/eslint-import-resolver-ts#configuration

@dukedave @bradzacher following on that discussion, shouldn't disabling those useless rules go into https://github.com/benmosher/eslint-plugin-import/blob/master/config/typescript.js ?

yup.
but not everyone thinks they're useless - not everyone uses the typescript compiler to typecheck their code (i.e. some people use babel + webpack), so they rely on eslint tooling to check things like imports.

This is why the import resolver exists - so people can use these tools if they want.
I would recommend just disabling it locally if you don't find value in it.