Preserve interfaces in generated declaration files for augmentation

[talks2much]

Suggestion

I'm so sorry I can't find any similar issues to this problem

🔍 Search Terms

Stop emitting never for empty interfaces from declaration

✅ Viability Checklist

My suggestion meets these guidelines:

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

⭐ Suggestion

Make TypeScript compiler preserve references to original Interfaces. (or at very least add an option for this!)

📃 Motivating Example

Playgroud link

export interface InterfaceToAugment {

}

export default <T extends keyof InterfaceToAugment>(key: T, value: InterfaceToAugment[T]) => { };

After we run tsc (with declaration: true of course) we'll see our .d.ts file:

export interface InterfaceToAugment {
}
declare const _default: <T extends never>(key: T, value: InterfaceToAugment[T]) => void;
export default _default;

As you can see here, declaration file making this interface absolutely useless., but I wanted to make this function to pick real keys of this interface.

Is there any workaround for this?

💻 Use Cases

Module Augmentation for library consumer

declare module "this-lib" {
  interface InterfaceToAugment {
    myCustomKey: 5
  }
}

---

Please, correct me if I missed something

[RyanCavanaugh]

@weswigham I was hoping this workaround would work, but it didn't (checked on nightly as well):

export interface InterfaceToAugment { }
export type InterfaceKey = keyof InterfaceToAugment;
export default <T extends InterfaceKey>(key: T, value: InterfaceToAugment[T]) => { };

Thoughts?

[theKashey]

Run into the same problem with project references as they produce declarations.

export const expectSideEffect = <
  K extends keyof IntegrationTraces, // expected to be augmented
  T extends IntegrationTraces[K],       // expected to be augmented
>(
  name: K,
  ...value: Parameters<T>
);

⬇️ produces ⬇️

export declare const expectSideEffect: <K extends "event", T extends IntegrationTraces[K]>(name: K, ...value: Parameters<T>) => Promise<Parameters<T>>;

Where event is the single key defined in the local package.

export interface IntegrationTraces {
  event(source: string, message: string): void;
}

---

This "inline" behavior is also working only within the same package boundary, while I was not able to disable inlining inside the package, I was not able to get it working outside, in the consumer's code.

[talks2much]

Hey, @theKashey this was initially reported by @zardoy. I don't really know what about your case, but as he said it is easy to workaround. Examples:

• source replace script
• source replace script

It seems that they are replacing unique key in codebase, but obviously it can't be accurate. But I hope you got the idea.

And since this issue didn't have any activity for about a year, I suppose developers extremely rarely use this feature.

[theKashey]

Interesting solution, not sure I can afford it in monorepo. Currently the best workaround seems to be keeping some d.ts manually written 😔

[jaulz]

Unfortunately, this is still an issue. It would be really nice instead of running a script after the build.