`moduleResolution: bundler` diverges from bundlers following node semantics in regards to `default` import

Bug Report

🔎 Search Terms

moduleResolution bundler node webpack default namespace

🕗 Version & Regression Information

• This is the behavior in every version I tried: 5.0.4 (the only one with moduleResolution: bundler

⏯ Playground Link

Repro case can be found here

🙁 Actual behavior

When resolving a .d.mts file that proxies to .d.ts in a CJS package with moduleResolution: bundler, TypeScript complains with an error like:

Property 'default' does not exist on type 'string'.ts(2339)

The reason that it complains about it is that TypeScript is resolving default import as if the .d.ts in this CJS package could export the "real" default export. webpack actually follows semantics coined by node and it loads the namespace object as the default export of that "cjs file".

So the type-level reality diverges there from runtime. At runtime, with webpack - it works exactly like it would work in node. TypeScript thinks that the intention was to load module.exports.default there though.

🙂 Expected behavior

I'm not exactly sure what's the expected behavior here because "resolving" like a bundler is quite under-specified and bundlers are not quite consistent when it comes to this. Even when we check this very same repro, we can see that I had to use defaultIsModuleExports: true in Rollup for it to behave the same. By default, Rollup behaves in the same way as TypeScript does.

cc @andrewbranch

Start by running the linked repro and tracing resolution from the .d.mts proxy to the .d.ts file under moduleResolution: bundler. Compare the observed TypeScript result with webpack, Node semantics, and Rollup's documented behavior. Done requires an agreed expected behavior and a regression case, but the issue does not identify the relevant source or test files.