TypeScript: improve refactor-rename behavior for merged declarations

[soul-codes]

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> {
   /* ... */
}

[mjbvz]

Moving upstream for further discussion

[OliverJAsh]

I think I'm also running into this. Reduced test case:

// other.ts
export const Foo = {};
export type Foo = {};

// main.ts
import { Foo } from './other';

const copy: Foo = Foo;

If I go into other.ts and rename the type Foo, the value name is not updated, which breaks usages in main.ts:

// other.ts
export const Foo = {};
export type FooRenamed = {};

// main.ts
import { FooRenamed } from './other';

const copy: FooRenamed = Foo;

Is this the same issue as you're describing @soul-codes?

One workaround I've found is to run the update at the import level (e.g. in main.ts).

[soul-codes]

@OliverJAsh what you described is exactly it.

Sadly I was unable to use workaround you suggest to rename the original declaration though (unless I misunderstood what you meant).

Aside: the behavior as seen above is the "correct" one in my opinion. It's consistent with other behavior elsewhere that a local rename shouldn't affect the name of the original declaration (this is analogous to, say, renaming foo in the object expression { foo } would yield { foo: fooRenamed } and not { fooRenamed })

[OliverJAsh]

Ah, I see different behaviour, probably because I've disabled typescript.preferences.renameShorthandProperties.