microsoft / microsoft/TypeScript

Preserve interfaces in generated declaration files for augmentation

Open
#42,853 7 comments 2 reactions 1 assignee View on GitHub

@weswigham is already working on this.

Since Feb 18, 2021.

Needs Investigation
Dominant language
Go
Stars
111k
Forks
14.3k
Avg merge
2d 4h
Merged PRs (30d)
132

Description

Suggestion

2023 Updat

We investigated this, and turns out its easy to workaround, just extract function's type into standalone type declaration. So its low priority for us now.

🔍 Search Terms

Stop emitting never for empty interfaces from declaration

✅ 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.)
  • [ 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

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.