Fix declaration emit synthesizing extensionless import() specifier under allowImportingTsExtensions + nodenext

[Copilot]

When using allowImportingTsExtensions: true with .ts-extension relative imports under module: nodenext, declaration emit was generating invalid extensionless import() type references for node_modules packages — import("mylib/lib/Box") instead of import("mylib/lib/Box.js") — causing TS2307 errors in the emitted .d.ts.

Root cause

GetAllowedEndingsInPreferredOrder in preferences.go checked the ESM+NodeNext special case as:

if syntaxImpliedNodeFormat == core.ResolutionModeESM && moduleResolutionIsNodeNext {

TypeScript 6 uses (syntaxImpliedNodeFormat ?? impliedNodeFormat), falling back to the file's implied node format when syntaxImpliedNodeFormat is not provided. The Go port was missing this fallback.

When tryGetModuleNameAsNodeModule calls with ResolutionModeNone, the ESM check was always false, yielding [TsExtension, Minimal, JsExtension, Index] instead of the correct [TsExtension, JsExtension]. With Minimal before JsExtension, processEnding picked the extensionless form for .d.ts declaration files.

Fix

• internal/modulespecifiers/preferences.go: When syntaxImpliedNodeFormat is ResolutionModeNone, fall back to resolutionMode (the file's default) before the ESM+NodeNext check — matching TypeScript's ?? semantics.

• testdata/tests/cases/compiler/declarationEmitImportSpecifierWithTsExtensionRelativeImport.ts: Regression test covering the exact repro: ESM package, .ts-extension relative import chain, node_modules subpath with .js extension, verified mod.d.ts output is now import("mylib/lib/Box.js").Box<string> with no TS2307.

• Fixes Behavior difference: declaration emit synthesizes extensionless import() specifier under allowImportingTsExtensions, invalid in nodenext #4616

[Copilot]

Pull request overview

This PR fixes a declaration emit module-specifier selection bug in the tsgo port that could synthesize extensionless import() type references under --module nodenext when allowImportingTsExtensions is enabled, leading to invalid emitted .d.ts (e.g. TS2307 due to missing .js).

Changes:

• Fix GetAllowedEndingsInPreferredOrder to fall back from syntaxImpliedNodeFormat to the file’s implied/default resolution mode when the syntax-implied mode is not provided (ResolutionModeNone), matching upstream ?? semantics.
• Add a compiler regression test reproducing the .ts-extension relative import chain and asserting .js is preserved in synthesized import() specifiers for node_modules subpaths.
• Add the corresponding reference baselines for the new test.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
internal/modulespecifiers/preferences.go	Implements the ResolutionModeNone fallback so ESM+NodeNext ending preferences are computed correctly.
testdata/tests/cases/compiler/declarationEmitImportSpecifierWithTsExtensionRelativeImport.ts	New regression test covering the reported nodenext + allowImportingTsExtensions declaration emit scenario.
testdata/baselines/reference/compiler/declarationEmitImportSpecifierWithTsExtensionRelativeImport.js	Reference baseline verifying emitted mod.d.ts contains import("mylib/lib/Box.js")....
testdata/baselines/reference/compiler/declarationEmitImportSpecifierWithTsExtensionRelativeImport.types	Reference types baseline for the new test case.
testdata/baselines/reference/compiler/declarationEmitImportSpecifierWithTsExtensionRelativeImport.symbols	Reference symbols baseline for the new test case.