moduleResolution: "bunder" with subpath exports does not support extensionless imports #60139
Closed as not planned
Description
🔎 Search Terms
moduleResolution bundler extension import export
🕗 Version & Regression Information
- This is the behavior in every version I tried, and I reviewed the FAQ for entries about : 5.5.3 and 5.6.2
⏯ Playground Link
https://github.com/croraf/typescript-import-issue
💻 Code
The application has a default Vite - ts+react template configuration. I try to reference modules from my custom library which has in package.json
"exports": {
".": {
"import": "./index.ts"
},
"./lib/*": {
"import": "./lib/*"
}
}In calling application I try to import the modules:
import Test from '@inxelo/components/lib/AutocompleteLargeDataset2.tsx'
import Test2 from '@inxelo/components/lib/AutocompleteLargeDataset2' // <--- this errors out🙁 Actual behavior
The import without extension errors out.
Cannot find module '@inxelo/components/lib/AutocompleteLargeDataset2' or its corresponding type declarations.ts(2307)
If I change moduleResolution: "node" it doesn't error out.
Runtime works fine (in the example it does not work cause it needs additional setup in the code, but in my production it works fine in runtime).
🙂 Expected behavior
Should allow both versions to be imported in the above setup.
Additional information about the issue
No response
Activity
Andarist commentedon Oct 4, 2024
How is this issue different from #60003 (where you have left a comment)? It feels like Andrew Branch (@andrewbranch)'s comment can just be quoted here:
It's not clear if you are using Vite here or some other setup but the rest of this comment is applicable nevertheless
croraf commentedon Oct 4, 2024
Mateusz Burzyński (@Andarist) Ryan Cavanaugh (@RyanCavanaugh) two differences
There the OP uses the
importsfeature and employs #.I do the
exportsin the library, and I dont use #.Andarist commentedon Oct 4, 2024
package.json#importsandpackage.json#exportsshare most of those rules. I don't expect the answer to be any different just because you refer to the other field than that other issue. Those were 2 fields introduced together~.croraf commentedon Oct 4, 2024
Ok. I don't really get the conclusion there.
If I understand correctly
moduleResolution: bundlermeans that module resolution for typescript check is somehow delegated to the bundler (the bundler set up by Vite in my case)?So I'm confused how does the subpath get resolved correctly at runtime and not for typescript check? Should I report a bug in Vite repository, or what is going on?
Andarist commentedon Oct 4, 2024
How I understand it is that
moduleResolution: bundleris a mode designed for a bundlers - but that is a pretty broad statements. There are multiple existing bundlers, all of them have some kind of quirks and weird behaviors unique to them. So this mode represents some kind of a common denominator behavior that was determined through trial & error (well, manual checks and creating a support table but u get the intention).It's impossible to create knobs for every little behavior that a particular bundler might get differently from others. It also wouldn't really be practical for the users. So this mode is a "best shot" at the problem.
Note that the behaviors of bundlers usually comes from pre-existing behaviors in runtimes like node. Traditionally extensionless imports (and
index.jsfiles) were supported by node so bundlers had to adopt them too.package.json#exports/importswere, again, introduced by node and they are much newer features. Those never supported any of that by design. So if any bundler implements it differently than node in this regard, I'd consider this to be a problem with that bundler and I'd encourage you to report this to the respective team. We don't need the ecosystem to diverge on this - it hurts code portability.typescript-bot commentedon Oct 7, 2024
This issue has been marked as "Duplicate" and has seen no recent activity. It has been automatically closed for house-keeping purposes.
croraf commentedon Oct 7, 2024
Ryan Cavanaugh (@RyanCavanaugh) Mateusz Burzyński (@Andarist)
I don't know. https://www.typescriptlang.org/docs/handbook/modules/reference.html#bundler marks extensionless relative imports same as Node/Node10 does and contrary to Node16/NodeNext, but when importing extensionless from packages behaves like the latter instead of the former.
Andarist commentedon Oct 7, 2024
package.json#exports/imports dont expose relative imports though. Those are more like pattern-matched aliases - you expose whatever u want and map that to files