Referenced project options not consulted to determine .d.ts format for synthetic default export eligibility

[dBianchii]

🔎 Search Terms

• default import has no default export
• missing default export not reported
• default import from named exports only
• should error: module has no default export
• no diagnostic for default import
• checker fails default import
• moduleResolution bundler default import
• bundler resolution default import missing
• TypeScript no error default import
• TS1192 Module has no default export not emitted
• TS1192 not raised with bundler
• TS2307 repro default import (historical term)
• composite project default import diagnostic
• monorepo workspace default import diagnostic

🕗 Version & Regression Information

This is the behavior in every version I tried (TypeScript 5.9.2 and typescript@next as of 2025‑08‑09)

⏯ Playground Link

https://github.com/dBianchii/ts2307-repro

💻 Code

// strict: true
// target: ES2022
// module: ESNext
// moduleResolution: bundler
// verbatimModuleSyntax: true
// allowSyntheticDefaultImports: false
// esModuleInterop: true

// filename: a.ts
export const test = () => "test";

// filename: b.ts
import Test from "./a"; // should error: module './a' has no default export
console.log(Test.test());

🙁 Actual behavior

pnpm -F @ts2307-repro/b typecheck (or just running tsc --build or even just tsc) completes with exit code 0 and no diagnostics, even though @ts2307-repro/b does a default import from a module that only has named exports.

🙂 Expected behavior

TypeScript should emit an error for the default import because ./a (or @ts2307-repro/a/src/Utils) has no default export.
The build should fail (non‑zero exit) under moduleResolution: bundler.

Additional information about the issue

Repros on macOS (Darwin 26.0 pnpm 10.13.1, TypeScript 5.9.2 and typescript@next (as of today).

[andrewbranch]

Your code sample errors in exactly the way you expect:

b.ts(1,8): error TS1192: Module '"a"' has no default export.


==== a.ts (0 errors) ====
    export const test = () => "test";
    
==== b.ts (1 errors) ====
    import Test from "./a"; // should error: module './a' has no default export
           ~~~~
!!! error TS1192: Module '"a"' has no default export.
    console.log(Test.test());

[andrewbranch]

The linked repo does show the issue. It’s an artifact of project references resolving the import to a .d.ts file that was built as part of a different project. In general, when we see a .d.ts file, we don’t know whether it represents an ESM or CJS JavaScript file. The declaration file content is export declare const test: () => string; but that could have been generated along with either of these:

export const test = () => {
  return 'test'
};

"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
exports.test = void 0;
const test = () => {
    return 'test';
};
exports.test = test;

If the JavaScript file looks like the latter, then a default import is legal. We opt to be more permissive given the uncertainty.

What we’re missing in this repro is that we can determine that the JS file is ESM by looking at the compiler options of the referenced project.