Importing modules from d.ts

[jeffrson]

Hi,

I have a case within a project that I tried to reduce to a minimal repro, see here: https://github.com/jeffrson/import_unresolved_dts

eslint with eslint-import-resolver-typescript apparently fails to recognize a module from d.ts, whether or not it is located in / or /@types.

startup.ts looks like this

import { ITest } from 'module1'

const i: ITest = { test1: '1' }
console.log(i)

and there's a file called my_modules.d.ts (name shouldn't matter):

declare module 'module1' {
    export interface ITest {
        test1: string
    }
}

which, when linting, shows the import/no-unresolved error.

[JounQin]

No idea how to fix this case easily. Maybe @bradzacher can help, because @typescript-eslint/eslint-plugin should also need to read custom .d.ts definitions.

But in another thought, eslint-plugin-import will just continue to resolve modules from node_modules, it is clear that this is no module1 source file (.js)

And also, if there are multiple modules defined at a single .d.ts, it will trigger a import/no-duplicates reporting: import-js/eslint-plugin-import#1479

So there will be no fix quickly.

[bradzacher]

Typescript-ESLint is built directly on top of TypeScript, so we don't need to worry about this. TS parses and checks all files together, so it implicitly finds and applies the module declaration.

This is essentially impossible for the resolver to handle. A .d.ts file can be literally anywhere in the project tree. There's nowhere special you can do to look for it.

If the module declaration declares a module from node_modules then it's fine and will "just work". But if you're defining fake modules that don't exist on disk...

Maybe consider instead defining a file somewhere in your project and using paths to map a name to it?

[JounQin]

@bradzacher Do you know is there a TypeScript API to search that?

[bradzacher]

There's probably something attached to the ts.Program object that comes back from the parse (which is returned as part of our parserServices.

Though I don't know offhand. There's a lot of data exposed on its properties and via the type checker.

TBH though if this project starts touching the type-information you'd really just be rebuilding typescript's module checks using typescript. And at that point you might as well just scrap all the logic and instead just gather and report the TS diagnostics.

[JounQin]

Yeah, I don't know whether worth to do that. I will do a research first recently.

[JounQin]

I think you should just use import/ignore or an ESLint disable comment for this case now. It's not worth to include TypeScript into this resolver because TypeScript itself has already done it.

[JounQin]

Or we can provide a simple mapper option to declare the mapping manually, if you want, PR welcome.

[linonetwo]

Same here

[linonetwo]

#197

#224