Removing lib.DOM dependency

[swapnil-nagar]

Removing the lib.DOM Dependency

Issue: #404

[swapnil-nagar]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[TsuyoshiUshio]

Potential Issues with Type Definitions

Thank you for this PR! Removing the lib.DOM dependency is the right approach. However, I noticed a few potential compatibility gaps in the new type definitions:

1. Missing FormData and URLSearchParams in HttpResponseBodyInit

The standard BodyInit type (from Web/Node.js Fetch API) includes:

type BodyInit = ReadableStream | Blob | ArrayBufferView | ArrayBuffer | FormData | URLSearchParams | string

The PR's definition:

type HttpResponseBodyInit = ReadableStream | Blob | ArrayBufferView | ArrayBuffer | string | null | undefined

Issue: FormData and URLSearchParams are missing. Users who pass these types as the response body will encounter type errors, even though it works at runtime.

2. HttpHeadersInit Missing Iterable Support

The standard HeadersInit type:

type HeadersInit = Headers | string[][] | Record<string, string> | Iterable<[string, string]>

The PR's definition:

type HttpHeadersInit = Headers | Record<string, string> | [string, string][]

Issue: Iterable<[string, string]> is not supported, so passing a Map<string, string> or other custom iterables will fail type checking.

3. Type Cast in HttpResponse.ts

this.#nativeRes = new Response(init.body as BodyInit, resInit);

This cast bypasses the type system. If HttpResponseBodyInit is narrower than what Node.js's Response actually accepts, there could be inconsistencies where valid runtime values fail type checking.

Suggested Fix

export type HttpResponseBodyInit = 
    | ReadableStream 
    | Blob 
    | ArrayBufferView 
    | ArrayBuffer 
    | FormData 
    | URLSearchParams 
    | string 
    | null 
    | undefined;

export type HttpHeadersInit = 
    | Headers 
    | Record<string, string> 
    | Iterable<[string, string]>;

Note: FormData and URLSearchParams are globally available in Node.js 18+, which aligns with the minimum supported version for Azure Functions Node.js v4 programming model.

4. Test Coverage

Consider adding tests for FormData and URLSearchParams body types to ensure full coverage.

---

Overall, this is a great improvement! Just these minor additions would ensure full backward compatibility with the original BodyInit and HeadersInit types.