RequestInit.signal type incompatibility blocks compiling on NodeJS

[devhawk]

There appears to be an issue in how RequestInit type is declared for DOM and Node 20.x that's blocking me from using oazapfts in server-side Node code.

in @types/node (v20.8.10), RequestInit type definition is imported from the undici-types package. In v5.26.5 of that package, RequestInit.signal is defined like this:

  signal?: AbortSignal // aka AbortSignal | undefined

In lib.dom.d.ts (TS 5.2.2), RequestInit.signal is defined like this:

    signal?: AbortSignal | null; // aka AbortSignal | null | undefined

Which is not compatible with the Node @types version.

It appears that oazapfts is compiled against the DOM declaration of RequestInit. The return type of json, form and multipart functions is not specified in code. The generated declaration file has the DOM version of RequestInit that supports null as an option for signal. Meanwhile, fetchText, fetchJson and fetchBlob all take a FetchRequestOpts as their 2nd argument.

From lib/runtime/index.d.ts in the oazapfts package

    fetchJson: <T extends ApiResponse>(url: string, req?: FetchRequestOpts) => Promise<WithHeaders<T>>;

    json({ body, headers, ...req }: JsonRequestOpts): {
        headers: {
            "Content-Type": string;
        };
        body?: string | undefined;
        baseUrl?: string | undefined;
        fetch?: typeof fetch | undefined;
        formDataConstructor?: (new () => FormData) | undefined;
        cache?: RequestCache | undefined;
        credentials?: RequestCredentials | undefined;
        integrity?: string | undefined;
        keepalive?: boolean | undefined;
        method?: string | undefined;
        mode?: RequestMode | undefined;
        redirect?: RequestRedirect | undefined;
        referrer?: string | undefined;
        referrerPolicy?: ReferrerPolicy | undefined;
        signal?: AbortSignal | null | undefined; // not compatible with Node's declaration of RequestInit
        window?: null | undefined;
    };

Arguably, the right solution here would be to update undici-types to match the declaration in lib.dom.d.ts and wait for that update to eventually get pulled into @types/node. However, oazapfts can work around this in one of two ways:

1. Explicitly specifying the return type of json, form and multipart as FetchRequestOpts.
2. Modify the implementation of those functions so that signal is always typed as AbortSignal | undefined, which is compatible with both DOM and Node's declaration of RequestInit.

    json({ body, headers, ...req }: JsonRequestOpts) {
      return {
        ...req,
        ...(body != null && { body: JSON.stringify(body) }),
        // the following line to forces signal's type to AbortSignal | undefined
        signal: req.signal ? req.signal : undefined,
        headers: {
          ...headers,
          "Content-Type": ensureJsonContentType(
            String(headers?.["Content-Type"]),
          ),
        },
      };
    },

I'm happy to open a PR to fix this. Please let me know which approach is preferable.

[Xiphe]

Thanks for bringing this up. Unless its a really easy fix I'd prefer when this can be sorted at the root-cause