using "export interface" produces import/named error

[gajus]

Declaration code:

export interface SourceInterface {
  search (query: string): Promise<SearchResultsType>
}

Import code:

import type {
  SearchResultsType,
  SourceInterface
} from './types';

Error:

/Users/gajus/Documents/[..]/src/sources/TestSource.js
  4:3  error    SourceInterface not found in '../types'          import/named

[gajus]

Invalid issue.

[sebn]

May I ask why it is invalid?

[gregtatum]

I am running into this now, and I believe this bug should be re-opened. There is no test covering this case, so at the very least there should probably be a test on this. Flow gives exporting and importing interfaces as a canonical example in their docs, so I believe this should work.

Thanks for the work on this plugin, it's been great at catching issues!

[ljharb]

@gajus can you elaborate on why you thought the issue was invalid?

[gajus]

@gajus can you elaborate on why you thought the issue was invalid?

Re-opened the issue as I cannot recall the original reason/ problem for tagging it as invalid.

[gajus]

I think I simply was unable to find documentation at the time proving that this syntax is valid.

Documentation for export {} syntax in general is a recent addition to the docs.

[ljharb]

export { } is valid; i'm not sure about export interface. Is that typescript? I don't think the eslint ecosystem works consistently with TypeScript yet.

[sebn]

It's flow syntax: https://flow.org/en/docs/types/modules/

On my side, if I remember correctly, I started using this plugin because I read somewhere it was supporting flow type imports, but I bumped into this error.

Hope this helps :)

[sebn]

(Can't remember where I read about flow type support though...)

[ljharb]

It definitely supports flow; I'm just not familiar with it is all :-)

[julienw]

Possibly #881 will fix this as well as issue #708 .

[spencerhakim]

I believe the issue lies here. typescript-eslint-parser has some extra AST node types, hopefully it's just a matter of adding the extra cases to support them (specifically, TSEnumDeclaration and TSInterfaceDeclaration should definitely be added, and I think TSNamespaceFunctionDeclaration as well, but I'm not sure about TSModuleDeclaration)

[benmosher]

FWIW, in general we've trying to allow/support Flow syntax but definitely rely on community support to keep that up to date. There is only as much testing/support for it as community members have provided.

@spencerhakim, you're saying TS's interface import/export will be processed if those TS node types are added alongside the Flow interface node type? (and tested to ensure whatever necessary fields are under the same names)

[benmosher]

BTW it is not clear to me whether the original issue with Flow syntax was fixed or not, by #881. Same thing goes for TypeScript as Flow: if it's easy and the community is up for it, will happily support more syntax.

[spencerhakim]

If no one else picks this up, I can put some time into a PR within the next week.

[spencerhakim]

FYI, the above PR passes all tests, but is marked as failing because a break statement decreased coverage by 0.04% 😑

[ljharb]

This should be fixed by #958.

[majelbstoat]

I think there was perhaps a regression with this? (edit: the syntax is subtly different, but still valid.)

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"

[ljharb]

New flow syntax often results in rules not working with it; can you open a new issue for that?