I'm thinking about changing the check to isTimeoutError: (error: unknown) => error is TimeoutError || error.name === HTTPError.name; to handle cross realm situations

last commit adds a fallback name check in case instanceof fails for some reason. let me know what you think

also idk if you want the helpers to be attached to the ky instance or keep them standalone

IMO, these functions should be standalone and not attached to the Ky instance.

I also think that, unlike isKyError(), the more specific functions provide limited value and probably shouldn't be included.

i think the specific type guards are beneficial for both internal and external use.

	if (isKyError(error)) {
		if (isHTTPError(error)) {
			console.log('Status:', error.response.status);
		} else if (isTimeoutError(error)) {
			console.log('Timeout URL:', error.request.url);
		}
	} 

I also replaced the internal instanceof checks with the new helper functions.
I'm thinking of passing a boolean parameter to enable the name check which defaults to false, we can call it crossRealmCheck or nameCheck

export function isHTTPError<T = unknown>(error: unknown, crossRealmCheck = false): error is HTTPError<T> {
    return error instanceof HTTPError || (crossRealmCheck && ((error as any)?.name === HTTPError.name));
}

i removed the name check for now but i can bring it back if you think it's useful

They should support name as a fallback. Otherwise they don't earn their keep. Needs to be worth the weight of an import.

My only issue is that name checking can produce false positives since other errors can potentially have the same name.
Should we still go through with the name check?

brought back the name checks

Just one more small nit. Otherwise LGTM.

The imports can be combined into a single line:

import ky, {TimeoutError} from 'ky';

it seems node 24 introduces Error.isError() (still not fully supported in safari) which works cross realm which means we can get rid of the name check and the instanceof check.

I don't see how that would be useful here. Error.isError() does not support comparisons to check if an object is one of our errors.

You're right but we can however use it to get rid of the as any type assertion.

(Error.isError(error) && error.name === HttpError.name);

instead of

((error as any)?.name === HTTPError.name);

but this requires bumping to node 24 but i don't think it's worth it until node 24 becomes the lowest maintenance release.

also until safari fixes its implementation because it currently returns false on DomExceptions : (