Typescript import/named with types in d.ts

[ThomasdenH]

I think I have found a bug with import/named. I have created a repository that reproduces the issue.

The line that gives problems is

import { AreaProps } from 'recharts';

It imports an interface defined in a d.ts file. The following warning is given:

1:10  error  AreaProps not found in 'recharts'  import/named

PR #1304 should solve importing types to typescript, but maybe this doesn't work for declaration files? Or is there something wrong with my configuration?

[manuelbieh]

Struggling with a similar issue and express-serve-static-core from node_modules/@types/express-serve-static-core. I don't get an import/named error but an import/no-unresolved error. Looks like .d.ts files aren't resolved properly

import { RequestHandler, Request } from 'express-serve-static-core';

results in an error:

8:41  error  Unable to resolve path to module 'express-serve-static-core'  import/no-unresolved

// edit:
looks like eslint still uses eslint-import-resolver-node instead of eslint-import-resolver-typescript:

eslint-plugin-import:resolver:node resolve threw error: { 
  Error: Cannot find module 'express-serve-static-core' from '.\src\server\middleware'
}

Minimal reproducible example here:
https://github.com/manuelbieh/eslint-typescript-import-bug

[pcorpet]

The problem seems to come for types installed through http://definitelytyped.org/.

[benmosher]

@ThomasdenH can you try using https://www.npmjs.com/package/eslint-import-resolver-typescript as your resolver and see if it fixes?

if it does, I think it may solve many TS-related issues. I just used it to solve some weird ones in my day job codebase

edit: I think it won't help after all, based on import-js/eslint-import-resolver-typescript#17 + associated PR but it's an easy experiment

[benmosher]

@manuelbieh I think your case is a little different than OP. I see you're using the typescript resolver but it works fine for me... and no-unresolved should report based on the existence of the true code file and not the types.

it would be possible for the typescript resolver to try a @types/... resolution but that would be in scope for that resolver, and not this plugin.

[pcorpet]

@benmosher , thanks the typescript resolver worked for me. Note for reference that you can have multiple import resolvers (I didn't want to turn off the webpack resolver so I hadn't tried the typescript one earlier).

[ThomasdenH]

@ThomasdenH can you try using https://www.npmjs.com/package/eslint-import-resolver-typescript as your resolver and see if it fixes?

if it does, I think it may solve many TS-related issues. I just used it to solve some weird ones in my day job codebase

edit: I think it won't help after all, based on alexgorbatchev/eslint-import-resolver-typescript#17 + associated PR but it's an easy experiment

Sorry for the late reply! Unfortunately it doesn't fix the issue, but thanks for the suggestion.

[benmosher]

@ThomasdenH: yep, makes sense. I didn't fully understand the scenario when I originally suggested.
@pcorpet: great! I'm doing the same thing -- I have the webpack resolver first for most things but the typescript resolver does resolution in some of my untranspiled first-party TS dependencies

[joelle-helgert-wittgruppe]

I am having the same issue for an intl-type that is generated by DefinitelyTyped. Is there any solution or further ideas on how to fix it?

[JounQin]

For anyone maybe interested, you can try eslint-import-resolver-typescript@JounQin/eslint-import-resolver-typescript#feat/resolve_dts temporarily (PR made at import-js/eslint-import-resolver-typescript#20).

[benmosher]

☝️ @JounQin's solution is my recommendation as the permafix. I haven't tried it myself but I scanned through the changes and they look like they should do the trick!

@JounQin: I'm not sure how to read that link. Did you publish your fork to npm?

[JounQin]

@benmosher It's just using npm package with github branch.

[dontsave]

I'm running into this issue as well. Imports from declarations are very common, so this is a real pain. It would be great to get a fix

[benmosher]

again, resolution is out of scope for this plugin. will close when @JounQin's PR is accepted or other similar fix is implemented by eslint-import-resolver-typescript (see #1341 (comment) above)

[hedgepigdaniel]

The way I understand it, its not possible for a resolver to solve this problem. Resolvers can only return a single file, but in this case of separate source and declaration files, the exports are distributed across 2 files.

e.g.

// file.d.ts
export type Fruit = {
  color: string,
};

// file.js
export const tomato = {
  color: 'red',
};

// index.ts
import { Fruit, tomato } from './file'; // <-- these exports do not come out of any one file

[JounQin]

@hedgepigdaniel You should add export const tomato: Fruit into .d.ts at the same time.

[JounQin]

@benmosher Should this issue be closed in favor of eslint-import-resolver-ts?

[w4-alibek]

Make sure you have inside the
package.json

{
  ....
  "dependencies": {
    "module-name": "version"
  },
  "devDependencies": {
    ...
    "@types/module-name": "version" // version should be same with dependencies
  }
  ....
}

[JounQin]

@benfletcher @ThomasdenH @ljharb @stekycz

This issue can be closed definitely in favor of eslint-import-resolver-typescript@2.0.0.

[hedgepigdaniel]

@JounQin which change in that new version addresses this issue?

[JounQin]

@hedgepigdaniel You can always read the CHANGELOG by yourself.

[ljharb]

@JounQin i've done so, and i have no idea which change addresses this issue. Could you clarify?

[JounQin]

@ljharb I was thinking we were in the same context here: import-js/eslint-import-resolver-typescript#20 (comment), didn't we?

And also #1341 (comment) and #1341 (comment)

[ljharb]

Yes but those don't tell me which specific commits in the changelog address this issue :-)

[JounQin]

@ljharb Did you read https://github.com/alexgorbatchev/eslint-import-resolver-typescript/blob/master/CHANGELOG.md#features?

• resolve .ts/.tsx/.d.ts first, and then fallback to @types/* (b11ede3)

---

I made that PR first and accidentally found it could fix this issue already. I don't think that's my responsibility to clarify that this issue has been fixed by another third party package which has been released.

[hedgepigdaniel]

Does that mean there is now a problem where if there is a declaration file, there is a false error when importing a value from the module that has the declarations?

[hedgepigdaniel]

I guess that isn't a problem if you have types for all exported symbols

[JounQin]

@hedgepigdaniel Sorry my English is not so good enough for understanding what's your point? Do you have an example?

---

Maybe I can understand what's your meaning now.

Of course, .d.ts should always contain all exported symbols from .js.

[hedgepigdaniel]

// apple.js

export const color = 'red';
export const shape = 'round';

// apple.d.ts

export const color: string;

// index.ts

// vv Error: shape is not defined in `apple.d.ts`!
import { shape } from './apple';

[JounQin]

@hedgepigdaniel Yeah, but that is a bad practice and should never happen.

[ljharb]

@JounQin it's not about what's your responsibility; it's about being friendly and helpful :-) Thanks for pointing me to import-js/eslint-import-resolver-typescript@b11ede3.

[JounQin]

@JounQin it's not about what's your responsibility; it's about being friendly and helpful :-) Thanks for pointing me to alexgorbatchev/eslint-import-resolver-typescript@b11ede3.

@ljharb Emm... I'm always friendly, but my pointed CHANGELOG and PR both target the same commit which fixed this issue. Maybe we both need to be more patient and find out the key point by ourselves? Cheers.