deps: update undici to 6.2.1

[nodejs-github-bot]

This is an automated update of undici to 6.2.1.

[targos]

Refs: #51108

Breaking change: The body stream will now be a byte stream/support byob mode.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/56511/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/56514/

[mhdawson]

rubber stand LGTM

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/56638/

[mcollina]

@KhafraDev can you please reference the change in undici that made this a semver-major? As far as I’m aware, this was not tagged accordingly in undici. Between v5 and v6, there was only one breaking change: dropping old Node.js version.

[KhafraDev]

@mcollina nodejs/undici#2482

[mcollina]

Found it, thanks!

[mcollina]

Can you please articulate in the undici PR body what's the breaking change is? There is very little context on it.

[marco-ippolito]

3 commits for the same version, thats weird, the script should have ignored them, also there is a typo (note 6.2.1.) in the pr description created by the bot that makes me think there is a bug in the update script. I unfortunaly cannot reproduce locally.

[KhafraDev]

the main difference was support for byob mode/byte streams, but adding range support to blob urls could break people unexpectedly too

[mcollina]

Could you make an example of code that would run on v5 and would not run anymore on v6?
From what I'm reading, this is a feature addition.

[KhafraDev]

the following would throw an error in v5:

const r = await fetch('https://www.google.com')
r.body.getReader({ mode: 'byob' })

When fetch was first implemented, streams weren't byob (it's a relatively new change to the spec). I wouldn't call it a bug fix because we were handling it correctly, until the spec changed.

Here's another example, even though it's likely less impactful:

const blob = new Blob(['hello world'])
const url = URL.createObjectURL(blob)

const r = await fetch(url, {
  headers: {
    range: 'bytes=0-5'
  }
})

console.log(await r.text())
// in v5 -> "hello world"
// in v6 -> "hello"

[targos]

First example is typically considered semver-minor.
Second example looks more like a bug fix.

[panva]

This begs the question how are bugfixes and security fixes going to trickle down to existing release lines? Are there still going to be v5.x undici releases to accomodate bug fixes, security fixes? Is the github action update script ready to pull those undici v5.x updates into v18/20/21-staging branches?

[richardlau]

Is the github action update script ready to pull those undici v5.x updates into v18/20/21-staging branches?

AFAIK the update script running on GitHub Actions only runs for main.

[panva]

Is the github action update script ready to pull those undici v5.x updates into v18/20/21-staging branches?

AFAIK the update script running on GitHub Actions only runs for main.

So with this update as semver-major the future v6.x PRs should be marked as dont-land-on-* as to not cause a headache for releasers until v6.x is in the latest release line.

I guess the implications of bumping major on undici as major on Node are giving me a headache. I think undici major changes should be getting accumulated (or not released as "latest") until right before the major version bump of nodejs so that bugfixes can flow into node's regular release lines.

[mcollina]

I concur with @targos, those are not majors.

(fetch has done major changes, but those do not look like it).

[mcollina]

Adding a feature or fixing a bug is not a breaking change. If a new version of undici removed support for byob streams, then that would be a breaking change.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/56703/

[targos]

Landed in 05f8172

[KhafraDev]

Adding a feature or fixing a bug is not a breaking change. If a new version of undici removed support for byob streams, then that would be a breaking change.

I think this should be clarified somewhere, or an accurate definition of "stable" be listed in the node docs.

The breaking changes I listed aren't bug fixes; there wasn't any wrong with it, other than being outdated. When written, undici made the correct assumptions according to the spec. There are bug fixes that I didn't mention for this reason.

While I understand adding a feature isn't a breaking change, these changes aren't adding anything - they're changing the preexisting behavior of the code. For example, blob url parsing existed in undici 5, but we didn't check the range header. Code that is written the exact same between these 2 versions behaves differently. Same with the stream change, although to a lesser extent.