(types) undici.Response cannot be assigned to Response

[panva]

Bug Description

type undici.Response cannot be assigned to type Response so that module authors can use globally available Response as a type but users may use undici as the implementation to obtain one.

Reproducible By

https://gist.github.com/panva/a350238b643aef7a77b29e6db395c3b9

git clone https://gist.github.com/panva/a350238b643aef7a77b29e6db395c3b9 response-type-reproduction
cd response-type-reproduction
npm i
npx tsc

Expected Behavior

The types should be compatible.

Logs & Screenshots

index.ts:4:3 - error TS2322: Type 'Promise<import("./node_modules/undici/types/fetch").Response>' is not assignable to type 'Promise<Response>'.
  Type 'import("./node_modules/undici/types/fetch").Response' is not assignable to type 'Response'.
    The types returned by 'headers.entries()' are incompatible between these types.
      Type 'SpecIterableIterator<[string, string]>' is missing the following properties from type 'HeadersIterator<[string, string]>': map, filter, take, drop, and 9 more.

4   return undici.fetch(url)
    ~~~~~~


Found 1 error in index.ts:4

[panva]

Okay, regardless of the "target" set in tsconfig.json there's always an error, but the above one is for "ESNext" and there is a different one otherwise, both probably need to be dealt with.

[KhafraDev]

I think the types are correct here. undici.fetch doesn't return a global response.

[panva]

I think the types are correct here. undici.fetch doesn't return a global response.

It's not the global that i'm questioning here, it's the type (well its typescript so really just the TS interfaces), and the those must conform (or extend) the global one's otherwise users cannot use an undici Response in places where the type (interface) of standard Response is expected.

Developers can opt-in to allow global-like objects by not doing an instanceof check and in those cases they will still refer to the TS type Response. But then undici Response cannot be passed solely because of types, not because the runtime not being ready for it.

[panva]

It's these helpers typings that are available in node's V8 already that are missing.

[hamza-elmoudden]

try to change Response to undici.Response
lik this
function req(url: string): Promise<undici.Response> {
return undici.fetch(url)
}

[panva]

try to change Response to undici.Response lik this function req(url: string): Promise<undici.Response> { return undici.fetch(url) }

That's really not the point, besides that, runtime-agnostic modules would not type their API with undici.Response.

[KhafraDev]

The issue afaict is that the DOM types replaced the old iterator(s) types with a "HeadersIterator". All we should need to do is implement something similar. Lmk if my understanding of the issue is wrong :)

[hamza-elmoudden]

That's really not the point, besides that, runtime-agnostic modules would not type their API with undici.Response.

You're right to point out that simply changing Response to undici.Response isn't the best solution, especially for runtime-agnostic modules

bat you can do return undici.fetch(url) as unknown as Promise
or small utility function that normalizes the response

lik this
type FetchResponse = Response | undici.Response;

function normalizeResponse(response: undici.Response | Response): FetchResponse {
return response as FetchResponse;
}

function req(url: string): Promise {
return undici.fetch(url).then(normalizeResponse);
}

[panva]

Again, i'm aware that users can ignore type inconsistencies by type casting, but that's not really the point here, they shouldn't need to.