Port #63038: Consult referenced project options for synthetic default export eligibility

[Copilot]

When a .d.ts file is resolved via a project reference, its module format was unknown, so canHaveSyntheticDefault would permissively allow synthetic defaults. This meant import Foo from './lib' against an ESM project reference with only named exports produced no error.

Changes

• internal/checker/checker.go: In canHaveSyntheticDefault, when GetImpliedNodeFormatForEmit returns no result for a declaration file, check whether the file originates from a project reference via GetRedirectForResolution or GetProjectReferenceFromOutputDts. If so, use GetEmitModuleFormatOfFile to resolve the module kind from the referenced project's options and deny synthetic defaults when both sides are ESM.

if targetMode == core.ModuleKindNone && file.AsSourceFile().IsDeclarationFile {
    if c.program.GetRedirectForResolution(file.AsSourceFile()) != nil || c.program.GetProjectReferenceFromOutputDts(file.AsSourceFile().Path()) != nil {
        targetModuleKind := c.program.GetEmitModuleFormatOfFile(file.AsSourceFile())
        if usageMode == core.ModuleKindESNext && core.ModuleKindES2015 <= targetModuleKind && targetModuleKind <= core.ModuleKindESNext {
            return false
        }
    }
}

• internal/execute/tsctests/tsc_test.go: Added test case "referenced project with esnext module disallows synthetic default imports".
• Baselines: Updated 2 existing baselines and added 1 new baseline, all consistent with the TypeScript submodule expectations.

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[DanielRosenwasser]

microsoft/TypeScript#63038

[Copilot]

Pull request overview

Ports TypeScript PR #63038 to ensure synthetic default imports are not permitted when importing a declaration file that comes from an ESM project reference, by consulting the referenced project’s emit module format.

Changes:

• Updated Checker.canHaveSyntheticDefault to consult referenced project compiler options (via project reference mapping) when implied node format can’t be determined for a .d.ts.
• Added a new project-references tsc test case covering module: esnext referenced projects and synthetic default imports.
• Updated/added tsc/tsbuild baselines to reflect the corrected TS1192 diagnostics and downstream type changes.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
internal/checker/checker.go	Tightens canHaveSyntheticDefault by inferring module kind from referenced project options for redirected .d.ts files.
internal/execute/tsctests/tsc_test.go	Adds a focused regression test for ESM project references disallowing synthetic default imports.
testdata/baselines/reference/tsc/projectReferences/referenced-project-with-esnext-module-disallows-synthetic-default-imports.js	New baseline demonstrating TS1192 errors for default imports from ESM project reference outputs.
testdata/baselines/reference/tsc/projectReferences/default-import-interop-uses-referenced-project-settings.js	Baseline updated to include the new TS1192 errors for referenced project imports.
testdata/baselines/reference/tsbuild/javascriptProjectEmit/loads-js-based-projects-with-non-moved-json-files-and-emits-them-correctly.js	Baseline updated to reflect TS1192 + resulting any types and updated tsbuildinfo diagnostics.

[Copilot]

The GetProjectReferenceFromOutputDts(...) != nil check appears redundant here: Program.GetRedirectForResolution already consults both the source-to-output and output-dts-to-source project reference maps (and symlink mapping). Dropping the extra lookup would simplify the condition and avoid implying there are two independent mechanisms to check.