Eslint-plugin-import: Import of Typescript interface is not recognised correctly

Created on 15 Jun 2018  路  12Comments  路  Source: benmosher/eslint-plugin-import

Opening per @ljharb. A similar issue was reported in https://github.com/benmosher/eslint-plugin-import/issues/726, but this is for Typescript interface imports.

Defined in react-select:

export interface Option<TValue = OptionValues> { // ... }

Imported:

import Select, { Option } from 'react-select'

Error:

[eslint] Option not found in 'react-select' (import/named)

Relevant packages:

    "eslint": "4.19.1",
    "eslint-plugin-import": "2.12.0",
    "typescript": "2.9.1",
    "typescript-eslint-parser": "16.0.0"
bug help wanted typescript

Most helpful comment

https://github.com/benmosher/eslint-plugin-import/issues/1282 is nearly a duplicate of this, but this issue also includes types provides through external .d.ts files.

I'm not sure if it is possible to deal with this 100% correctly without a full type checker pass; a possible workaround is to check if there is a .d.ts available for parsing its imports instead before checking other extensions, but that won't work with declare module-style declarations (which can declare any module name they want if they're in ambient context).

@typescript-eslint/eslint-plugin will either need its own rule for this, or eslint-plugin-import should be taught to make use of the type services from @typescript-eslint/parser when they are available instead of using its own resolver/parser.

All 12 comments

Historically eslint (and thus, eslint plugins) have only supported Flow, not TypeScript.

I think adding typescript support is a pretty massive effort, but if it can be done easily, that sounds fine.

Just ran into this, too:

import moment, {Moment} from 'moment';

error:

1:17  error  Moment not found in 'moment'             import/named

In that case, moment is CJS, so it only has a default export.

TypeScript also pulls in the type information from it's .d.ts file:

https://github.com/moment/moment/blob/develop/moment.d.ts#L413

https://github.com/benmosher/eslint-plugin-import/issues/1282 is nearly a duplicate of this, but this issue also includes types provides through external .d.ts files.

I'm not sure if it is possible to deal with this 100% correctly without a full type checker pass; a possible workaround is to check if there is a .d.ts available for parsing its imports instead before checking other extensions, but that won't work with declare module-style declarations (which can declare any module name they want if they're in ambient context).

@typescript-eslint/eslint-plugin will either need its own rule for this, or eslint-plugin-import should be taught to make use of the type services from @typescript-eslint/parser when they are available instead of using its own resolver/parser.

After upgrading to 2.17.1 this is fixed for me 馃帀

Awesome, closing (happy to reopen if people are still experiencing it)

Unfortunately, this issue still exists in 2.17.2 (using @typescript-eslint/parser as recommended in the Typescript section of eslint-plugin-import Readme [not the now deprecated typescript-eslint-parser mentioned in the configuration above])

@alesn would you mind opening a new issue and shading a minimal reproduction?

Has this issue been resolved for anyone who uses @typescript-eslint/parser, which should now be used?

I will double check that and let you know

@alesn Sorry I forgot to answer you earlier.

Yes I am running "@typescript-eslint/parser": "^1.6.0" and "eslint-plugin-import": "^2.17.1".
There is also 2.17.2 out in the meantime.

In .eslintrc.js I have

parser: '@typescript-eslint/parser',
overrides: {
  files: ['**/*.ts', '**/*.tsx'],
  parser: '@typescript-eslint/parser',
  rules: {
    'import/namespace': 'off',
    'import/no-duplicates': 'off',
    'import/no-unresolved': 'off',
    'no-restricted-globals': 'off',
    'no-undef': 'off'
  }
},

Hope that helps.

Was this page helpful?
0 / 5 - 0 ratings