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"
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.
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.tsfiles.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.tsavailable for parsing its imports instead before checking other extensions, but that won't work withdeclare module-style declarations (which can declare any module name they want if they're in ambient context).@typescript-eslint/eslint-pluginwill either need its own rule for this, oreslint-plugin-importshould be taught to make use of the type services from@typescript-eslint/parserwhen they are available instead of using its own resolver/parser.