TypeScript refactorings should not generate explicit generic type arguments for types that the source interface has omitted due to the existence of defaults

Suggestion

🔍 Search Terms

List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily and help provide feedback.

• refactor
• generic
• parameter
• type
• arguments
• default
• expand

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

I use generic default arguments all the time, and much of my system's core set of interfaces includes the use of one or more generic parameters, most of which have defaults because there are many contexts in which I don't care about the type arguments and so I want my defaults to be used.

The refactorings offered by TypeScript for generating method stubs and so on always include all generic defaults preloaded into the stubs, even though the method definition on the interface itself does not specify any type arguments.

In short, I am forever having to correct the code generated by TypeScript to remove all of the unwanted redundant type arguments it has included. If I wanted to be forced to specify the arguments every time, I wouldn't have provided defaults. TypeScript should acknowledge my omission of type arguments by following suit when it generates code that refers to types I've defined elsewhere.

📃 Motivating Example

Consider the following two interfaces, the second of which includes an unconstrained reference to the first:

interface Foo<T = any> {
  readonly data: T;
}

interface Bar {
  method (foo: Foo): void;
}

I now want to quickly scaffold a class that implements Bar, so I type the following into VSCode:

class Foo implements Bar {}

I now select the refactoring to "Implement interface 'Bar'":

This now generates the following method stub:

class Foo implements Bar {
  method (foo: Foo<any>): void { // <any> is redundant - It should not have been included here
    throw new Error('Method not implemented.');
  }
}

If my interface doesn't provide explicit type arguments, then neither should the refactoring.

💻 Use Cases

This feature request is a general productivity issue. Especially when I am rapidly iterating on a codebase and making heavy use of generic types with more complex interfaces than what I described above, I've sometimes even found myself copying and pasting other code from my codebase rather than using the refactoring, just because I can't be bothered going through and deleting all the unwanted type arguments TypeScript has generated.

Start with the TypeScript language-service entry point for the “Implement interface 'Bar'” refactoring and reproduce the Foo/Bar example from the issue. Trace how the generated method parameter type is formed, then add regression coverage showing that omitted default generic arguments remain omitted and verify the generated stub matches the requested wording.