import-x/named resolver bug related to invalid type definitions

[silverwind]

Reproduction:

git clone https://github.com/silverwind/resolver-bug
cd resolver-bug
npm install
npx eslint index.js

Will raise:

1:9  error  foo not found in 'mod'  import-x/named

mod/index.js exports the variable, but mod/index.d.ts which is erronous as it refers a non-existant file does not include that export (which is likely a separate bug in vite-plugin-dts which I'm using to generate these type defs).

Deleting mod/index.d.ts makes it work, but imho it should just ignore such invalid type definitions and fall back to actual code, like it already does when no type defs are present.

This was working in a previous version, but I can't pinpoint which one exactly.

[JounQin]

This was working in a previous version, but I can't pinpoint which one exactly.

Does downgrading resolver-typescript to <3.7.0 works as you expected?

I'd make sure that's indeed a regression.

[silverwind]

I tried downgrading all involved dependencies to versions where I know it worked, but no luck so far. Maybe the root cause is in some indirect dependency.

One thing I noticed is the error goes away when I remove this setting, so it seems to be involved:

"import-x/extensions": [".js", ".jsx", ".ts", ".tsx"]

[JounQin]

But clearly it should work as you expected, I'll take a look when I'm free.

[silverwind]

Thanks. Meanwhile I will enable rollupTypes in vite-plugin-dts which bundles the type definition files into one and seems to produce valid definitions without broken import statements.

[JounQin]

Hmm... I took a look at the reproduction again, I misunderstood the issue, it's not a bug, the malformed export * from "./nonexist.ts"; doesn't provide correct foo export, and resolving mod/index.d.ts is just expected, if you try export * from "./nonexist.ts"; export const foo: string; the there will no report.

export * from "./nonexist.ts"; is not broken in the parser view.

So, closing as working expected.

[silverwind]

if you try export * from "./nonexist.ts"; export const foo: string; the there will no report.

That's not possible to do thought because I currently publish my npm modules as JS, not TS and some runtimes like Node.js forbid loading Typescript code from node_modules.

I still think this is a regression, but I can accept it because ultimately it's a bug in the type definition generation.

[JounQin]

My example is for mod/index.d.ts not the source code, so no .ts interception by Node itself.

I don't think we ever supported your expected fallback behavior, if it did then it was bug, .d.ts is preferred in resolver-typescript as documented, and is the only source when resolving exported symbols.

[silverwind]

Yeah in the real code, mod is in node_modules/mod. I do hope that node will at some point allow loading typescript from node_modules because type definition files are are a useless relic of the past imho and a pointless pain to have.

[JounQin]

I never talked about TypeScript stripping?

[silverwind]

Ah I misunderstood. Yes of course having a export const foo: string; in mod/index.d.ts will work.

What I was getting at was that if only mod/index.ts existed, there would not be ambiguity whether the resolver should prefer mod/index.d.ts ormod/index.js, so it is forced to use the single .ts file. And for that to work in node_modules, Node.js needs to enable type stripping for modules in node_modules.

[JounQin]

I believe it's out of scope here. 😅

[silverwind]

Yeah, as long as the resolver can load node_modules/mod/index.ts, there is nothing to do for it.

[silverwind]

I've improved the reproduction and found the actual culprit being eslint-import-resolver-typescript and in turn oxc-resolver:

import-js/eslint-import-resolver-typescript#429.