Fix: Consult referenced project options for synthetic default export eligibility

[Copilot]

Fix for Referenced Project Options Not Consulted for Synthetic Default Export Eligibility

✅ All steps completed:

• Create proper test that reproduces the bug
• Implement fix using correct ES module range check
• Use both getRedirectFromSourceFile and getRedirectFromOutput for robustness
• All tests pass
• Lint and format pass

Summary

This PR fixes an issue where TypeScript doesn't check default imports from project reference .d.ts files.

Changes

Modified canHaveSyntheticDefault in src/compiler/checker.ts:

• Keeps original getImpliedNodeFormatForEmit logic for node16/nodenext (lines 3787-3795)
• Added check for non-node16/nodenext cases (lines 3797-3810):
  • Only when getImpliedNodeFormatForEmit returns undefined
  • Only for declaration files from project references
  • Tries both getRedirectFromSourceFile and getRedirectFromOutput to find project references
  • Uses host.getEmitModuleFormatOfFile(file) to get the referenced project's module format
  • Disallows synthetic defaults when format is ES module (using range check: ES2015 <= kind <= ESNext)

Key improvements:

1. Correct ES module range check: Changed from >= ModuleKind.ES2015 to ModuleKind.ES2015 <= targetModuleKind && targetModuleKind <= ModuleKind.ESNext to exclude Node16+ (100-199) and Preserve (200) which have higher numeric values but aren't pure ES modules.

2. Robust redirect lookup: Uses getRedirectFromSourceFile || getRedirectFromOutput since declaration files can be mapped either way depending on resolution context.

Added test: referenced project with esnext module disallows synthetic default imports validates the fix.

Updated baselines: Tests correctly show errors for project references while keeping node_modules permissive.

Impact

// lib/utils.ts (referenced project with module: "esnext")
export const test = () => "test";

// app/index.ts (references lib)
import Test from '../lib/utils';  // Now errors: TS1192 Module has no default export

Project references with ES modules get correct diagnostics. Node_modules packages remain permissive.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Referenced project options not consulted to determine .d.ts format for synthetic default export eligibility</issue_title>
<issue_description>### 🔎 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).
</issue_description>

<agent_instructions>Something like host.getRedirectFromSourceFile(sourceFile.path)?.resolvedRef?.commandLine.options can be used to get referenced project options, you can search checker.ts for similar usage. Make sure your test actually reproduces the bug, noting that the OP test case does not. Replicate the repro in https://github.com/dBianchii/ts2307-repro in a test</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@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());
```</body></comment_new>
<comment_new><author>@andrewbranch</author><body>
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:

```js
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.</comment_new>

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

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[andrewbranch]

At the top of the function, there's

const usageMode = file && getEmitSyntaxForModuleSpecifierExpression(usage);
if (file && usageMode !== undefined) {
  const targetMode = host.getImpliedNodeFormatForEmit(file);

The host methods called from there should already be looking up the project reference redirect via getCompilerOptionsForFile in program.ts, so I'm actually wondering why this wasn't already doing the trick. I think your added condition of referencedModuleKind >= ModuleKind.ES2015 is insufficient because in --module nodenext there are more complex conditions that determine the output format of files, which made me realize this possibly should have already been handled above. Please debug and investigate what's happening in those calls when we're processing the referenced project's declaration file.

[Copilot]

At the top of the function, there's

Investigated the early-return logic at lines 3786-3796. The issue is that getImpliedNodeFormatForEmit only returns definitive ESNext/CommonJS values for node16/nodenext modules or files with specific extensions/package.json settings. For module: esnext with moduleResolution: bundler, it doesn't return a useful value, so the early-return conditions aren't met. The declaration file section is the appropriate place for this check, and using getEmitModuleKind (as suggested) ensures we handle all module kind computations correctly, including nodenext complexity. (commit d392ebd)

[andrewbranch]

@copilot there's a related function getEmitModuleFormatOfFile which is similar to getImpliedNodeFormatForEmit but falls back to getEmitModuleKind rather than returning undefined/none outside of node16/nodenext. I don't recall if that function is currently on CheckerHost but it should be easy to wire up if not. If we replace getImpliedNodeFormatForEmit with that function, perhaps the block of code you added will be superfluous?

[Copilot]

@copilot there's a related function getEmitModuleFormatOfFile which is similar to getImpliedNodeFormatForEmit but falls back to getEmitModuleKind rather than returning undefined/none outside of node16...

Replaced with getEmitModuleFormatOfFile which falls back to getEmitModuleKind as suggested. Added the check specifically for project reference declaration files (using host.getRedirectFromSourceFile) to avoid being too strict with node_modules packages. This makes the manual redirect checking code superfluous while keeping node_modules permissive. (commit 5a2ac97)

[andrewbranch]

@copilot I meant on line 3787

[Copilot]

@copilot I meant on line 3787

Kept getImpliedNodeFormatForEmit on line 3787 as originally designed. Added a conditional check (lines 3796-3806) that uses getEmitModuleFormatOfFile only when getImpliedNodeFormatForEmit returns undefined AND the file is a project reference declaration file. This maintains the original logic for node16/nodenext while adding project reference support, and keeps node_modules packages permissive. (commit 0d532eb)

[andrewbranch]

@copilot what happens when you replace line 3787 and delete the rest of your added code? If that's wrong explain to me what's going wrong and why

[Copilot]

@copilot what happens when you replace line 3787 and delete the rest of your added code? If that's wrong explain to me what's going wrong and why

Replacing line 3787 with getEmitModuleFormatOfFile and deleting my added code causes the "ambiguous-package" test to fail. The issue: for node_modules packages (not project references), getCompilerOptionsForFile returns the consuming project's options, not the package's. So getEmitModuleFormatOfFile returns the app's module kind (ESNext), making line 3792 (targetMode >= ES2015) incorrectly trigger for packages where we can't determine the actual format. We need to check getRedirectFromSourceFile to distinguish project references (where we know the format) from node_modules (where we don't).

[Copilot]

Pull request overview

This PR fixes an issue where TypeScript doesn't properly check default imports from project reference declaration files. When importing from a project reference with ESM module format, TypeScript should disallow synthetic default imports if the imported module only has named exports.

Changes:

• Added logic in canHaveSyntheticDefault to check project reference options when determining module format for declaration files
• Added a new test case to verify the fix works for project references with ESNext module
• Updated baselines to reflect the new errors for project reference imports

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
src/compiler/checker.ts	Added lines 3797-3809 to check referenced project options and disallow synthetic defaults for ESM project references
src/testRunner/unittests/tsc/projectReferences.ts	Added test case "referenced project with esnext module disallows synthetic default imports"
tests/baselines/reference/tsc/projectReferences/referenced-project-with-esnext-module-disallows-synthetic-default-imports.js	New baseline showing the expected error for default import from ESM project reference
tests/baselines/reference/tsc/projectReferences/default-import-interop-uses-referenced-project-settings.js	Updated baseline to include additional errors for project reference imports (lines 89-90)

[Copilot]

For declaration files from project references, consider using getRedirectFromOutput instead of getRedirectFromSourceFile. The function getRedirectFromSourceFile maps source file paths to project references, while getRedirectFromOutput maps output file paths to project references. Since this code block handles declaration files (outputs), using getRedirectFromOutput(file.path)?.resolvedRef would be more semantically correct and consistent with the pattern in getRedirectReferenceForResolution (program.ts:2112).

[andrewbranch]

@copilot investigate whether this suggestion is correct, and apply the other suggestion above (#63038 (comment))

[Copilot]

Investigated and found that getRedirectFromOutput alone doesn't work for all test cases. Using the pattern from getRedirectReferenceForResolution, I now try both getRedirectFromSourceFile || getRedirectFromOutput since declaration files can be mapped either way depending on resolution context. This ensures the check works regardless of how the file was resolved. (commit d7ac3ad)

[andrewbranch]

Test coverage now proves this works the same whether you try to import the input .ts file or output .d.ts file of the referenced project, so current implementation seems good

[andrewbranch]

@typescript-bot test top800

[typescript-bot]

Starting jobs; this comment will be updated as builds start and complete.

Command	Status	Results
test top800	✅ Started	✅ Results

[andrewbranch]

The presence of these errors was actually always asserted in the test content (lines 66–67 in the baseline). Not sure if this used to work and regressed without noticing or what, but this baseline change matches the original intention.

[typescript-bot]

@andrewbranch Here are the results of running the top 800 repos with tsc comparing main and refs/pull/63038/merge:

Everything looks good!