TypeScript export and import/named rule

[kirill-konshin]

TypeScript's exported types/interfaces does not work with import/named rule.

File 'xxx.ts':

export type ScpRouteProps = ReactRouter.RouteProps & {
    access?: boolean;
    title: string;
};

Then import it in different file:

import {ScpRouteProps} from './xxx';

Will result in error:

7:5  error  ScpRouteProps not found in './xxx'    import/named

Same error when importing:

import {WrappedFieldProps} from 'redux-form';
// 1:9  error  WrappedFieldProps not found in 'redux-form'                import/named

Or

import {AutoSizer, Column, ColumnProps, Table, TableProps} from 'react-virtualized';
// /xxx/web/src/components/VirtualizedTable.tsx
//  3:28  error  ColumnProps not found in 'react-virtualized'  import/named
//  3:48  error  TableProps not found in 'react-virtualized'   import/named

[ljharb]

It seems like the right thing to do here is to include TypeScript export type exports in the ExportMap, which should make everything Just Work.

[kirill-konshin]

Not just type, interfaces too. Basically, all "not real" exports. Any ideas how to do that? I'm totally not familiar with plugin's codebase...

[ljharb]

Presumably somewhere in https://github.com/benmosher/eslint-plugin-import/blob/master/src/ExportMap.js#L335 - cc @benmosher

[jpickwell]

May also want to check a package's package.json for a types key which points to a TypeScript type definition file (*.d.ts).

[Primajin]

Weirdly export type foo isn't recognized for me anymore, while export interface bar is.

[bradennapier]

Was the ExportMap a comment about how to fix this bug via PR or is there some config to fix this? Just hit this one as well :-\ pretty major rule to disable.

Ah ok guessing the case statement needs to just have whatever ts is calling its type declarations?

case 'TSEnumDeclaration':
case 'TSInterfaceDeclaration':
case 'TSAbstractClassDeclaration':
case 'TSModuleDeclaration':

[bradennapier]

@ljharb got this fixed in pr #1304 - any way to get this merged ASAP? It kills our libraries pretty badly and we are a large part through moving to eslint from tslint. :-)

[ljharb]

@bradennapier even if it were; there's only one person who can cut a release, so it's not likely to be published asap.

[bradennapier]

Ahh, ok thanks.

[schmod]

FYI, this only appears to happen when using @typescript-eslint/parser, but works correctly with (the now-deprecated) typescript-eslint-parser.

[JSteunou]

like @schmod said the bug is present with when using @typescript-eslint/parser and unfortunately still present, I dont understand why, @bradennapier fix seemed ok

[JSteunou]

it seems to only happen when the type are in a separate index.d.ts file

[dontsave]

I'm getting this issue with @typescript-eslint/parser as well. Perfectly fine named exports are erroring while being imported.

import { ThemeProps } from 'styled-components' currently errors.

[laustdeleuran]

I'm experiencing this error as well, with the package react-intl v2.9.0.

import { InjectedIntlProps } from 'react-intl'; currently errors.

[PejmanNik]

So in the import-js/eslint-import-resolver-typescript#31 it passed to eslint-plugin-import and here pass it back? how I can help to resolve this issue?
Thank you

[apedroferreira]

I'm still getting this, for example when importing the Keyframes interface from styled-components:

import { Keyframes as KeyframesType } from 'styled-components'

[dawndong1988]

it seems to only happen when the type are in a separate index.d.ts file

The same. Is there any solution? We have to disable the rule for now.

[Maxim-Mazurok]

Issue seems to appear when importing interface from @types folder. If package has index.d.ts in it's own folder - it works fine.

Adding this to .eslintrc.js:

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

seems to solve this problem.
Unfortunetly, it introduces another issue: No default export found in imported module "react" import/default when doing import React from "react" or import * as React from "react".

[ljharb]

That’s because typescript’s module system is broken unless you enable synthetic imports and es module interop. If you enable those, what happens?

[Ffdominikkoller]

Just to give a feedback, i had same issue and had all tried that should fix this issue. Nothing helped. So i played more with the settings and fixed it with setting the babel/env preset modules to "commonjs". Was set to "false".
So babelrc:

"presets": [
        [
            "@babel/env",
            {
                "useBuiltIns": "entry",
                "corejs": 3,
                "modules": "commonjs"
            }
        ],
        "@babel/react",
        "@babel/typescript"
    ]

[g3tr1ght]

Just to give a feedback, i had same issue and had all tried that should fix this issue. Nothing helped. So i played more with the settings and fixed it with setting the babel/env preset modules to "commonjs". Was set to "false".
So babelrc:

"presets": [
        [
            "@babel/env",
            {
                "useBuiltIns": "entry",
                "corejs": 3,
                "modules": "commonjs"
            }
        ],
        "@babel/react",
        "@babel/typescript"
    ]

I'm afraid you're missing the point of modules entry in babel/env preset and most likely you aren't running eslint cli, but rather using it as a webpack (or other bundler) plugin/loader.
Here's why this particular combination works for you:

eslint-plugin-import/src/rules/named.js

Line 79 in 94d6739

!options.commonjs

And if you use "modules": "commonjs" (especially in production), as a result you have larger bundle size, since webpack can't tree-shake commonjs.

[Shunya078]

Issue seems to appear when importing interface from @types folder. If package has index.d.ts in it's own folder - it works fine.

I found a similar problem and am now using the following to ignore the lint rules. (Because there is no problem in the behavior on the web)
// eslint-disable-next-line import/named

Currently, interfaces are defined in a set of files called "interfaces".
Is it possible to make the type definitions of the folders in the "interfaces" county generally acceptable in my files?

I apologize if this is a lack of knowledge on my part. Please respond.

[n10v]

Possible solution that works for us:

import type { Keyframes } from 'styled-components'

But it's only available for TS3.8+