Port #60195: Allow reusing type nodes that resolve to error types

[Copilot]

This change ports microsoft/TypeScript#60195 to the Go implementation, fixing an issue where error types in isolated declarations mode would cause cascading errors.

Problem

When using isolated declarations with unresolved imports, the compiler would generate additional confusing errors beyond the initial module resolution error. For example:

// @isolatedDeclarations: true
import { Unresolved } from "nonexistent-module";

export const foo = (type?: Unresolved): void => {};

Previously, this would not only report the module resolution error but also additional type reuse errors, making the output harder to understand.

Solution

Added error type handling to the tryReuseExistingNonParameterTypeNode function in internal/checker/nodebuilderimpl.go. When an annotation type resolves to an error type, the function now allows reusing the type node to prevent cascading errors.

The change follows the same logic as the TypeScript implementation:

• If annotationType is an error type, allow reusing the existing type node
• This prevents cascading errors in isolated declarations mode
• For source code with errors, there's no guarantee to emit correct code anyway

Changes

• Modified tryReuseExistingNonParameterTypeNode in internal/checker/nodebuilderimpl.go
• Added 6 lines of code with appropriate comments explaining the behavior
• No breaking changes or API modifications

Testing

• All existing tests pass
• No baseline changes required (the fix prevents errors rather than changing outputs)
• Verified the change builds successfully

Fixes #7.

---

💡 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.