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
The headers property in the DispatchOptions interface currently uses IncomingHttpHeaders. Since this property is used for outgoing HTTP requests, it would be more appropriate to type it as OutgoingHttpHeaders.
In addition to the typing issue, there is an inconsistency between the documentation and the actual TypeScript definitions in the code. According to the documentation (see screenshot below), the headers property is described as:
headers: UndiciHeaders | string[] (optional)
In contrast, the TypeScript definition for DispatchOptions in the codebase defines headers as:
While reviewing the typing of headers in DispatchOptions, I noticed a similar issue in the ConnectOptions interface, where the headers are also typed as IncomingHttpHeaders. This makes me wonder if there might be a broader issue with the typing of headers across the library. Perhaps there was an intention to use a generic type for headers, but it seems like only one of the possible types (likely IncomingHttpHeaders) has been applied throughout
The text was updated successfully, but these errors were encountered:
Bug Description
The headers property in the DispatchOptions interface currently uses IncomingHttpHeaders. Since this property is used for outgoing HTTP requests, it would be more appropriate to type it as OutgoingHttpHeaders.
In addition to the typing issue, there is an inconsistency between the documentation and the actual TypeScript definitions in the code. According to the documentation (see screenshot below), the headers property is described as:
headers: UndiciHeaders | string[] (optional)
In contrast, the TypeScript definition for DispatchOptions in the codebase defines headers as:
Additional Observation
While reviewing the typing of headers in DispatchOptions, I noticed a similar issue in the ConnectOptions interface, where the headers are also typed as IncomingHttpHeaders. This makes me wonder if there might be a broader issue with the typing of headers across the library. Perhaps there was an intention to use a generic type for headers, but it seems like only one of the possible types (likely IncomingHttpHeaders) has been applied throughout
The text was updated successfully, but these errors were encountered: