The convertTo*.ts files contain functions that currently include a @ts-expect-error comment to bypass a TypeScript error related to the use of a generic return type. For example, in the convertToAll function, the issue arises because the return type, which is a generic GetApiResponse<"all", DataByCode>, isn't properly recognized by the TypeScript linter, leading to type-checking issues.
Affected Code Example:
export async function convertToAll<
Schema extends SchemaType,
Method extends MethodType,
Route extends RoutesForMethod<Schema, Method>,
DataByCode extends Record<number, unknown> = RouteResponsesByStatusCode<
Schema,
Method,
Route
>,
>(
response: Promise<AxiosResponse>,
): Promise<GetApiResponse<"all", DataByCode>> {
return (
response
// @ts-expect-error You can't do it any other way, that's the end of my rope
.then<GetApiResponse<"all", DataByCode>>((response) => ({
response,
error: null,
status: response.status,
data: response.data,
}))
.catch<GetApiResponse<"all", DataByCode>>((error) => {
if (!axios.isAxiosError(error)) {
return {
error,
data: undefined as never,
response: undefined,
status: undefined,
};
}
return {
error,
status: Number(error.response?.status) || undefined,
data: error.response?.data || undefined,
response: error.response,
} as GetApiResponse<"all", DataByCode>;
})
);
}
Problem:
The TypeScript linter fails to properly handle the generic return type GetApiResponse<"all", DataByCode>. This forces the use of @ts-expect-error, which is not ideal for maintaining type safety and can obscure underlying issues. The problem lies in the complexity of the generic type, which the linter cannot fully resolve.
Task:
- Investigate why the TypeScript linter is unable to process the generic return type.
- Explore potential refactoring or alternative type declarations that would allow TypeScript to correctly infer and validate the return type.
- Remove the
@ts-expect-error comment and ensure that the function passes type-checking without errors.
Resolving this issue is important for ensuring that the function's type safety is verifiable by the linter, preventing potential runtime errors and improving the maintainability of the code.
The convertTo*.ts files contain functions that currently include a @ts-expect-error comment to bypass a TypeScript error related to the use of a generic return type. For example, in the convertToAll function, the issue arises because the return type, which is a generic GetApiResponse<"all", DataByCode>, isn't properly recognized by the TypeScript linter, leading to type-checking issues.
Affected Code Example:
Problem:
The TypeScript linter fails to properly handle the generic return type
GetApiResponse<"all", DataByCode>. This forces the use of@ts-expect-error, which is not ideal for maintaining type safety and can obscure underlying issues. The problem lies in the complexity of the generic type, which the linter cannot fully resolve.Task:
@ts-expect-errorcomment and ensure that the function passes type-checking without errors.Resolving this issue is important for ensuring that the function's type safety is verifiable by the linter, preventing potential runtime errors and improving the maintainability of the code.