July 29, 2025

@whatwg-node/node-fetch@0.7.24

Patch Changes

• #2643
  941e5ce
  Thanks @ardatan! - In case of iterator cancellation, ensure the
  response stream a.k.a. IncomingMessage is properly closed.

  const response = await fetch('http://localhost:3000/stream')
  
  for await (const chunk of response.body) {
    console.log('Received chunk:', chunk)
    if (chunk === 'stop') {
      console.log('Stopping stream')
      // In case of `break` which calls the `iterator.return()`, we need to ensure the stream is closed properly.
      break
    }
  }

July 28, 2025

@whatwg-node/node-fetch@0.7.23

Patch Changes

• #2632
  7a44c69
  Thanks @ardatan! - Avoid Node's promise pipeline by piping streams
  directly

@whatwg-node/server@0.10.11

Patch Changes

• #2640
  22c568e
  Thanks @ardatan! - Handle string bodies without streams to fix the
  performance regression

July 17, 2025

@whatwg-node/fetch@0.10.9

Patch Changes

• #2553
  752b0eb
  Thanks @renovate! - Fix the conflict of urlpattern-ponyfill
  and `@types/node`

• Updated dependencies
  [b69157b]:

  • @whatwg-node/node-fetch@0.7.22

@whatwg-node/node-fetch@0.7.22

Patch Changes

• #2578
  b69157b
  Thanks @ardatan! - Avoid .toArray and use Readable's native
  listeners directly

May 22, 2025

@whatwg-node/server@0.10.10

Patch Changes

• #2452
  19c0be5
  Thanks @ardatan! - Support AbortSignal.any on Node.js

• #2452
  19c0be5
  Thanks @ardatan! - Prevent custom AbortSignal to log
  "MaxListenersExceededWarning"

May 20, 2025

@whatwg-node/fetch@0.10.8

Patch Changes

• #2424
  28c4ad9
  Thanks @ardatan! - Performance optimizations

  • Avoid creating AbortController and AbortSignal if not needed with new Request because it
    is expensive
  • Avoid creating a map for Headers and try to re-use the init object for Headers for
    performance with a single-line writeHead.
  • Avoid creating Buffer for string bodies for performance
  • Use setHeaders which accepts Headers since Node 18 if needed to forward Headers to Node

• Updated dependencies
  [28c4ad9]:

  • @whatwg-node/node-fetch@0.7.21

@whatwg-node/node-fetch@0.7.21

Patch Changes

• #2424
  28c4ad9
  Thanks @ardatan! - Performance optimizations

  • Avoid creating AbortController and AbortSignal if not needed with new Request because it
    is expensive
  • Avoid creating a map for Headers and try to re-use the init object for Headers for
    performance with a single-line writeHead.
  • Avoid creating Buffer for string bodies for performance
  • Use setHeaders which accepts Headers since Node 18 if needed to forward Headers to Node

@whatwg-node/server@0.10.9

Patch Changes

• #2424
  28c4ad9
  Thanks @ardatan! - Performance optimizations

  • Avoid creating AbortController and AbortSignal if not needed with new Request because it
    is expensive
  • Avoid creating a map for Headers and try to re-use the init object for Headers for
    performance with a single-line writeHead.
  • Avoid creating Buffer for string bodies for performance
  • Use setHeaders which accepts Headers since Node 18 if needed to forward Headers to Node

• 1642a76
  Thanks @ardatan! - Remove unnecessary workaround for Bun

• Updated dependencies
  [28c4ad9]:

  • @whatwg-node/fetch@0.10.8

May 16, 2025

@whatwg-node/server@0.10.8

Patch Changes

• 8eb332c
  Thanks @ardatan! - Workaround for the bug in Node 24 and Deno don't
  like bound disposal functions

May 16, 2025

@whatwg-node/node-fetch@0.7.20

Patch Changes

• #2414
  1f0b643
  Thanks @ardatan! - Improvements for Node 24 and use once from
  node:events for Promise-based event handling whenever possible

@whatwg-node/server@0.10.7

Patch Changes

• #2431
  085186b
  Thanks @renovate! - Fix explicit resource management for Deno

May 10, 2025

@whatwg-node/fetch@0.10.7

Patch Changes

• #2383
  9527e8f
  Thanks @ardatan! - Some implementations like compression npm
  package do not implement response.write(data, callback) signature, but whatwg-node/server waits
  for it to finish the response stream. Then it causes the response stream hangs when the
  compression package takes the stream over when the response data is larger than its threshold.

  It is actually a bug in compression package;
  expressjs/compression#46 But since it is a
  common mistake, we prefer to workaround this on our end.

  Now after calling response.write, it no longer uses callback but first it checks the result;

  if it is true, it means stream is drained and we can call response.end immediately. else if it
  is false, it means the stream is not drained yet, so we can wait for the drain event to call
  response.end.

• Updated dependencies
  [9527e8f]:

  • @whatwg-node/node-fetch@0.7.19

@whatwg-node/node-fetch@0.7.19

Patch Changes

• #2383
  9527e8f
  Thanks @ardatan! - Some implementations like compression npm
  package do not implement response.write(data, callback) signature, but whatwg-node/server waits
  for it to finish the response stream. Then it causes the response stream hangs when the
  compression package takes the stream over when the response data is larger than its threshold.

  It is actually a bug in compression package;
  expressjs/compression#46 But since it is a
  common mistake, we prefer to workaround this on our end.

  Now after calling response.write, it no longer uses callback but first it checks the result;

  if it is true, it means stream is drained and we can call response.end immediately. else if it
  is false, it means the stream is not drained yet, so we can wait for the drain event to call
  response.end.

• Updated dependencies
  [d86b4f3]:

  • @whatwg-node/promise-helpers@1.3.2

@whatwg-node/promise-helpers@1.3.2

Patch Changes

• #2408
  d86b4f3
  Thanks @slagiewka! - Reuse fake promise Symbol

@whatwg-node/server@0.10.6

Patch Changes

• #2383
  9527e8f
  Thanks @ardatan! - Some implementations like compression npm
  package do not implement response.write(data, callback) signature, but whatwg-node/server waits
  for it to finish the response stream. Then it causes the response stream hangs when the
  compression package takes the stream over when the response data is larger than its threshold.

  It is actually a bug in compression package;
  expressjs/compression#46 But since it is a
  common mistake, we prefer to workaround this on our end.

  Now after calling response.write, it no longer uses callback but first it checks the result;

  if it is true, it means stream is drained and we can call response.end immediately. else if it
  is false, it means the stream is not drained yet, so we can wait for the drain event to call
  response.end.

• Updated dependencies
  [d86b4f3,
  9527e8f]:

  • @whatwg-node/promise-helpers@1.3.2
  • @whatwg-node/fetch@0.10.7

April 14, 2025

@whatwg-node/server@0.10.5

Patch Changes

• b9f3629
  Thanks @enisdenjo! - dependencies updates:
  • Updated dependency
    @whatwg-node/fetch@^0.10.6 ↗︎
    (from ^0.10.5, in dependencies)

April 14, 2025

@whatwg-node/fetch@0.10.6

Patch Changes

• #2310
  f699a1b
  Thanks @enisdenjo! - dependencies updates:
  • Updated dependency
    @whatwg-node/node-fetch@^0.7.18 ↗︎
    (from ^0.7.11, in dependencies)