Use auto-imports for isolatedDeclarations fixes

[Daniel Rosenwasser (DanielRosenwasser)]

Fixes microsoft/TypeScript#63846.

[Copilot]

Pull request overview

This PR updates the isolatedDeclarations “missing type annotation on exports” code fix to use the auto-import system so that the fix can add required imports (including import type) when the inferred annotation references types from files that aren’t currently imported (Fixes #4411).

Changes:

• Wire autoimport.ImportAdder into the isolated-declarations type annotation fixer and include its edits in produced code actions (single-fix and fix-all).
• Propagate createImportAdder/auto-import preparation errors through the code action pipeline.
• Add a new fourslash regression test covering annotation + auto-import when the type originates in an unimported file.

Show a summary per file

File	Description
internal/ls/codeactions_fixmissingtypeannotation.go	Use ImportAdder to add imports for synthesized types during isolatedDeclarations annotation fixes.
internal/fourslash/tests/codeFixMissingTypeAnnotationOnExportsUsingTypeFromUnimportedFile_test.go	Regression test ensuring the fix adds a type annotation and a new import type when needed.

Copilot's findings

• Files reviewed: 2/2 changed files
• Comments generated: 1

[Daniel Rosenwasser (DanielRosenwasser)]

One reason I think I didn't push this PR harder earlier is I didn't want us to create a distinct import adder for every fix. Might not be a big deal.

[Jake Bailey (jakebailey)]

We already do worse in other places, just look at getCodeActionsToFixClassIncorrectlyImplementsInterface which creates one for every single type node in an implements, so surely it's not a big deal?

[Daniel Rosenwasser (DanielRosenwasser)]

Technically one of the test names doesn't fit into this file name but it's not a huge deal.

[Daniel Rosenwasser (DanielRosenwasser)]

I had an idea for auto-import logic that is strictly bounded by the current program, and Andrew Branch (@andrewbranch) had a few ideas around it - but I think just backing off if something isn't in scope and auto-imports aren't available is fine.

[Copilot]

Review details

Suppressed comments (2)

Previously missed (1) — in code that hasn't changed since the last review.

internal/ls/codeactions_fixmissingtypeannotation.go:1209

• This also assumes the auto-imported binding can use the exported symbol name embedded in referenceTypeNode. If the file already declares a different Thing, the node builder emits import("./types").Thing, but AddImportFromExportedSymbol currently creates import type { Thing } without choosing an alias (autoimport/import_adder.go:101-114, 258-272). The action then adds a duplicate binding and prints : Thing, which still refers to the conflicting local declaration. The import adder needs to return the chosen local name so the synthesized type reference can be rewritten consistently.

		if f.importAdder != nil {
			for _, symbol := range importableSymbols {
				f.importAdder.AddImportFromExportedSymbol(symbol, true /*isValidTypeOnlyUseSite*/)
			}

internal/ls/codeactions_fixmissingtypeannotation.go:1210

• importAdder != nil does not guarantee that an import was registered. AddImportFromExportedSymbol explicitly returns without adding a fix when the symbol is filtered by autoImportFileExcludePatterns (autoimport/import_adder.go:102-109), but this path still replaces import("...").Thing with bare Thing. The resulting code action therefore introduces an unresolved type for excluded files (and similarly for any symbol for which no import fix can be produced). Please make import registration report success and bail out unless every inaccessible symbol was actually imported.

		if f.importAdder != nil {
			for _, symbol := range importableSymbols {
				f.importAdder.AddImportFromExportedSymbol(symbol, true /*isValidTypeOnlyUseSite*/)
			}
		} else if !f.allSymbolsAccessibleInScope(importableSymbols, enclosingDecl) {

• Files reviewed: 2/2 changed files
• Comments generated: 0 new
• Review effort level: Balanced

[Daniel Rosenwasser (DanielRosenwasser)]

Copilot tests are failing

[Jake Bailey (jakebailey)]

Copilot started, then gave up? Maybe during the outage

[Daniel Rosenwasser (DanielRosenwasser)]

Copilot make sure build/test/format is clean and working.

[Copilot]

Copilot make sure build/test/format is clean and working.

Confirmed clean at acd3825: npx hereby build, npx hereby test, and npx hereby lint all pass with no errors. npx hereby format (dprint) fails in my sandbox only because plugins.dprint.dev is unreachable (DNS blocked) — it can't even reach the point of checking the changed files. I verified formatting compliance directly against the changed Go files with gofmt -l and gofumpt -l (the same formatter dprint's gofumpt plugin wraps), and both report no diffs.

[Ryan Cavanaugh (RyanCavanaugh)]

Thank you for contributing to the TypeScript native port!

Development has moved from this repository back to the main microsoft/TypeScript repository. GitHub does not have PR transfer functionality, so we're closing this PR here.

If this change is still relevant, please reopen it as a new pull request in microsoft/TypeScript. We'd appreciate your help carrying the contribution over, and we apologize for the extra work.

See microsoft/typescript-go#4918 for more information about the move.