elastic / kibana

Your window into the Elastic Stack
https://www.elastic.co/products/kibana
Other
19.67k stars 8.23k forks source link

[kbn/server-route-repository] Improve type inference when using IKibanaResponseFactory #198677

Open miltonhultgren opened 3 weeks ago

miltonhultgren commented 3 weeks ago

We have added support for returning the result's from KibanaResponseFactory. This works well with our inference when using the ok function since we can unwrap the object we pass back.

But when using any of the error codes, our inference breaks down because they are typed as any, so which ends up overshadowing any other type information we try to provide.

We should find some way to alter these types or make them changeable so that we can better infer the shape of the error objects. Perhaps if they are changed to unknown or never instead that could improve the situation.

Note: In general it is better for performance to define explicit return types on the handler since it means less inference work for the TypeScript compiler to do

elasticmachine commented 3 weeks ago

Pinging @elastic/obs-knowledge-team (Team:obs-knowledge)

miltonhultgren commented 15 hours ago

@awahab07 Just as an example, if we change this line:

conflict(options?: ErrorHttpResponseOptions): IKibanaResponse;

to

conflict(options?: ErrorHttpResponseOptions): IKibanaResponse<never>;

Then that seems to fix it but I don't know what the impact of this would be, or if it semantically makes sense. I believe it does (there will never be a payload because the HTTP client will interpret those status codes as errors and throw instead), but we need to validate that with the Core team perhaps.