TypeScript: improve refactor-rename behavior for merged declarations

Currently, if you have e.g. a function-namespace merged declaration, or an interface-namespace merged declaration, attempting to refactor-rename one component of the merged declaration keeps the other components name unchanged. For example, if you rename the function, the merged namespace doesn't rename.

The result is that the merged declaration becomes unmerged.

An unfortunate consequence of this is that other files referencing the merged declaration don't seem to be able to decide which name to keep, with the current behavior being keeping the name in its usage (e.g. a function call).

My proposal is that the behavior change to renaming every component of the merged declaration, such that the overall merged property of the declaration is not destroyed.

My justification for it is that the developer has intentionally merged the declaration, and the rename action should preserve this intention. If the developer intentionally chooses to break the merge, it is that developer's responsibility to manually ensure all references import the right former merge components' new names after the unmerge, this being something the machine likely cannot accurately decide on the human's behalf.

Use cases

I often do merge declarations to keep declarations and implementations in the same file while keeping the export space relatively tidy. The intention is to scope names that are particular to some principal functionality instead of having e.g. myFunction , ResultForMyFunction, ArgForMyFunction polluting the export space (and thereby the auto-import suggestions).

In all cases below, it makes sense that a refactor-rename attempt would rename all components of the merged declarations.

Here is an example for a React component and its props.

export namespace SomeReactComponent {
   export interface Props {
      // ...
   }
}

export function SomeReactComponent(props: SomeReactComponent.Props){
   /* ... */
}

Here is another example of an API payload schema and its runtime declaration

export namespace SomeApiPostPayload {
   export function validate(value: unknown): value is SomeApiPostPayload {
      // 
  }
}

export interface SomeApiPostPayload {
   // ...
}

This is also especially useful when you have a function that relies on some kind of external context for dependency inversion and you would like to employ interface segregation hierarchically so that what you need to provide just kind-of "emerges":

// foo.ts
export namespace foo {
    export interface Context {}
}

export function foo(/* ..., */ context: foo.Context){
    // ...
}

// bar.ts
export namespace bar {
    export interface Context {}
}

export function bar(/* ..., */ context: bar.Context){
    // ...
}

// foobar.ts
import { foo } from "./foo.ts";
import { bar } from "./bar.ts";

export namespace foobar {
    export interface Context extends foo.Context, bar.Context {}
}

export function foobar(/* ..., */ context: foobar.Context){
    // ...
}

Or in the cases where result and error types are particular to a module rather than a project-wide shared data structure.

export namespace foo {
   export interface Result { /* ... */ }
   export interface Error { /* ... */ }
}

// assume type Failable<Success, Failure> = 
//   ({ ok: true } & Success) | ({ ok: false } & Failure)
// or some such notion
export function foo(): Failable<foo.Result, foo.Error> {
   /* ... */
}

Riproduci refactor-rename sugli esempi function-namespace e interface-namespace nell’issue, inclusi i riferimenti provenienti da altri file. Traccia il comportamento di refactor-rename per le dichiarazioni unite e definisci come completato il rinominare ogni componente, preservando l’unione e aggiornando i riferimenti in modo coerente.