You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using parameter destructuring, a function's parameter list includes the names of local variables. The compiler should not include these local variable names in the generated .d.ts file, because they are an internal implementation detail. Although omitting the local variables would have no operational effect on the declaration, doing so would improve readability, particularly when these signatures end up on an API documentation website.
logMessage is an implementation detail. It increases the size of the .d.ts file without having any observable effect to consumers of the printTitle() API.
What shortcomings exist with current approaches?
Imagine the above signature is displayed on an API documentation website or VS Code IntelliSense preview. The audience reading this signature may be confused by variables such as logMessage. What is that? Where are the docs for logMessage.
API Extractor also triggers an API review workflow whenever the type signature changes. Omitting implementation details from the .d.ts signature might avoid some false alarms for inconsequential changes.
What workarounds are you using in the meantime?
A .d.ts rollup tool such as API Extractor could automatically trim these extraneous tokens. However safely trimming them is a nontrivial operation as the AST changes in each compiler release. It would be much better for the compiler to implement this feature.
The text was updated successfully, but these errors were encountered:
π Search Terms
parameter destructuring rename .d.ts declaration
β Viability Checklist
β Suggestion
When using parameter destructuring, a function's parameter list includes the names of local variables. The compiler should not include these local variable names in the generated .d.ts file, because they are an internal implementation detail. Although omitting the local variables would have no operational effect on the declaration, doing so would improve readability, particularly when these signatures end up on an API documentation website.
π Motivating Example
Consider this API source code:
book.ts
The compiler emits this .d.ts file which includes both
title
(the destructuring source field) andlogMessage
(the target local variable):book.d.ts
π» Use Cases
What do you want to use this for?
logMessage
is an implementation detail. It increases the size of the .d.ts file without having any observable effect to consumers of theprintTitle()
API.What shortcomings exist with current approaches?
Imagine the above signature is displayed on an API documentation website or VS Code IntelliSense preview. The audience reading this signature may be confused by variables such as
logMessage
. What is that? Where are the docs forlogMessage
.API Extractor also triggers an API review workflow whenever the type signature changes. Omitting implementation details from the .d.ts signature might avoid some false alarms for inconsequential changes.
What workarounds are you using in the meantime?
A .d.ts rollup tool such as API Extractor could automatically trim these extraneous tokens. However safely trimming them is a nontrivial operation as the AST changes in each compiler release. It would be much better for the compiler to implement this feature.
The text was updated successfully, but these errors were encountered: