-
-
Notifications
You must be signed in to change notification settings - Fork 139
Description
Issue description
The implications of the never type means you will never be able to observe the type which isn't true in the case of 204 as those are usually represented through undefined. 204 is an OK status code, so throwing an Exception to satisfy the semantics of never doesn't make sense.
In the Typescript handbook, they describe it as appropriate for use in methods which always return an exception as you cannot observe the value even in try catch blocks. The only exception to this case I can think of is process.exit() being typed as returning never, but that also makes sense as you cannot observe that return type.
In practice, this requires extra code to cast as a route result type even if the return of making the request through some other function is any. Users of my lib that implements these types have also complained that it makes writing mocks for the real functions annoying, or even impractical in the case of JS without writing a bunch of type annotations or ts-ignore directives over each offending entry. Attached is an image of such a case
Code sample
// From the library as an example of needing to cast
// The return type of RequestHandler.request is Promise<any> which the semantics of any
// implies it can be ANYTHING, but it errors with never and nothing else.
public async leaveGuild(guildId: string): Promise<RESTDeleteAPICurrentUserGuildResult> {
return this.requestHandler.request(Endpoints.USER_GUILD("@me", guildId), {}, "delete") as RESTDeleteAPICurrentUserGuildResult;
}Package version
0.38.38
Runtime
Node.js
Runtime version
v24.13.0
Priority this issue should have
Low (slightly annoying)