@whatwg-node/fetch

Patch Changes

• #3642 ed29dc2 Thanks @ardatan! - Follow the Fetch standard when the Node HTTP transport follows redirects.

  fetchNodeHttp recursed on every 3xx Location while redirect was 'follow' (the default) and never counted hops. A response that always redirects could keep one fetch call issuing requests until the process ran out of memory. Following now stops after 20 redirects. The promise rejects with TypeError: Fetch failed: Maximum number of redirects (20) reached and code TooManyRedirects. A chain of 20 redirects that then returns a normal response still completes.

  That path also reused the previous request's Headers object for the next hop. A cross-origin Location therefore received Authorization, Proxy-Authorization, Cookie, Cookie2, and an explicit Host. Those headers are removed when the origin changes. The scheme is part of the origin, so an https to http redirect drops them too. Same-origin redirects still send them. Removal happens on a new header list, so the caller's own Headers object is left unchanged.

  301 and 302 responses to POST, and 303 responses to any method other than GET or HEAD, are resent as GET with no body. The request-body headers go with the body: Content-Encoding, Content-Language, Content-Location, Content-Type, and Content-Length. 307 and 308 keep the method and body when that body can be sent again. A one-shot stream cannot, and that redirect rejects.

  A cross-origin redirect whose URL includes a username or password is rejected with TypeError when the request mode is cors. Following it would send those URL credentials to the new origin as Authorization.

  A resent FormData body is encoded again with a new multipart boundary of the same length, so its Content-Length stays valid. Content-Type is replaced because that header names the boundary.

  redirect: 'error' rejects with a TypeError. A redirect whose target scheme is not http or https also rejects with a TypeError. redirect: 'manual' still returns the redirect response.

  Response.redirect() serializes an absolute URL into the Location header and throws TypeError when that URL cannot be parsed. A relative URL is stored as given, so Response.redirect('/') sets Location to /. The status must be 301, 302, 303, 307, or 308; any other status throws RangeError. The response status text is empty.

  @whatwg-node/fetch uses this transport on Node, so the same limits apply there.

Minor Changes

• #3561 52a5bf6 Thanks @ardatan! - Drop support for Node.js 18 and 20. The minimum supported Node.js version is now 22.15.

Why

Node.js 18 and 20 are end-of-life and no longer receive security updates. Keeping them in our support matrix forced version-specific workarounds and slowed adoption of newer Node TLS APIs.

The floor is set to 22.15 (not just 22.0) so we can rely on tls.getCACertificates() (Node.js 22.15 / 23.10) and always-on zlib zstd helpers (createZstdCompress / createZstdDecompress, Node.js 22.15 / 23.8). That matches the oldest currently supported LTS line (22 Maintenance) while dropping only EOL majors.

SemVer

• 0.x packages: minor bump (breaking changes are allowed in minors while major is 0).

• 1.x packages (@whatwg-node/promise-helpers, @whatwg-node/server-plugin-cookies): major bump, since dropping supported Node versions is a breaking engines change for SemVer >=1.0.0 consumers.

What changed

• engines.node: all published packages now declare >=22.15.0 (including @whatwg-node/promise-helpers, which was still on >=16).

• @whatwg-node/events: removed. Native CustomEvent / Event / EventTarget are available on Node.js 22+, so the ponyfill is no longer maintained; use the platform globals.

• @whatwg-node/fetch: dropped the require("crypto").webcrypto fallback; crypto is always globalThis.crypto on supported runtimes.

• @whatwg-node/server: removed the Node 18 setHeaders workaround (isNode1x); ServerResponse#setHeaders is used whenever it exists.

• @whatwg-node/node-fetch: Runtime guards for zlib.createZstdCompress / createZstdDecompress are removed; zstd is always included in Accept-Encoding.

• CI / e2e: unit matrix is [22, 24, 26]; AWS Lambda runtime and Azure Function target moved from Node 20 to Node 22.

If you are still on Node 18 or 20, upgrade to Node.js 22.15+ (or 24 / 26) before installing this release.

• #3604 b726b83 Thanks @ardatan! - Drop the optional node-libcurl dependency.

  The ponyfill HTTP transport now always uses node:http / node:https. The fetchCurl code path and the globalThis.libcurl runtime check have been removed.

  HTTP/2 support that previously came from node-libcurl is no longer available in this release; a follow-up adds optional undici-based transport (including HTTP/2).

  If you were relying on node-libcurl being picked up automatically, the ponyfill will now use the built-in Node.js HTTP stack instead.