jsdom environment turns every Blob/File request body into the string "undefined"

[harshit-d3v]

Describe the bug

Under environment: 'jsdom', a Blob or File used as a request body arrives as the literal string undefined. Nothing throws, so a test uploading a file passes while sending nine bytes of ASCII instead of its content.

const blob = new Blob(['hello world'], { type: 'text/plain' })
const text = await new Request('http://x.test/', { method: 'POST', body: blob }).text()

environment	text
node	"hello world"
happy-dom	"hello world"
jsdom	"undefined"

Same for a File inside FormData: the multipart part body is undefined, and fetch(URL.createObjectURL(blob)) returns undefined too.

Cause

makeCompatBlob in packages/vitest/src/integrations/env/jsdom.ts bridges jsdom's Blob to Node's fetch by reading a private field:

const buffer = (blob as any)[implSymbol]._buffer
return new NodeBlob_([buffer], { type: blob.type })

jsdom 28.0.0 renamed that field to _bytes, so the read is undefined and new Blob([undefined]) stringifies it.

jsdom	impl keys
24.1.3 – 27.4.0	_buffer,_globalObject,type
28.1.0 – 29.1.1	_globalObject,type,_bytes

Vitest's own devDependency is jsdom: ^29.1.1, so the default combination is the broken one. The existing tests in test/unit/test/environments/jsdom.spec.ts use an empty new Blob() and only assert toBeInstanceOf, which is why CI stays green.

Reproduction

The snippet above, in any project with vitest@5.0.1 and jsdom@29, run once per environment. A single test file:

import { expect, test } from 'vitest'

test('blob bytes survive a Request body', async () => {
  const blob = new Blob(['hello world'], { type: 'text/plain' })
  const text = await new Request('http://x.test/', { method: 'POST', body: blob }).text()
  expect(text).toBe('hello world')
})

Passes with --environment=node and --environment=happy-dom, fails with --environment=jsdom.

System Info

vitest 5.0.1
jsdom 29.1.1
node 22.18.0
win32 x64

Used Package Manager

npm

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines
• Read the docs
• Check that there isn't already an issue that reports the same bug
• Check that this is a concrete bug
• The provided reproduction is a minimal reproducible example of the bug

I used Claude to help investigate this. I ran the reproduction myself across the three environments and the six jsdom versions above.

[hi-ogawa]

The existing tests in test/unit/test/environments/jsdom.spec.ts use an empty new Blob() and only assert toBeInstanceOf

Where is this?

[Greidal]

Hit this again on vitest@4.1.11 + jsdom@30.1.0, but through a different call path than the original report - constructing a Request with a FormData body containing a Blob/File entry, not URL.createObjectURL:

const form = new FormData()
form.append('file', new Blob(['hello'], { type: 'text/plain' }), 'hello.txt')

const req = new Request('http://x.test/upload', { method: 'POST', body: form })
await req.text() // throws

TypeError: Cannot read properties of undefined (reading '_buffer')
 ❯ invokeTheCallbackFunction node_modules/jsdom/lib/generated/idl/Function.js:19:26
 ❯ FormData.forEach node_modules/jsdom/lib/generated/idl/FormData.js:420:18

I traced it to the same createCompatUtils/makeCompatBlob in packages/vitest/src/integrations/env/jsdom.ts that #11295 touched - makeCompatFormData calls formData.forEach(), and for each Blob entry calls makeCompatBlob, which is the function #11295 patched.

I think #11295's fix is incomplete, though, at least for this path. I patched a local install of vitest@4.1.11 with the exact merged diff (impl._bytes ?? impl._buffer) and re-ran the repro above - it still throws, just with '_bytes' instead of '_buffer' in the message now. Dug further and found why:

const implSymbol = Object.getOwnPropertySymbols(Object.getOwnPropertyDescriptors(new window.Blob()))[0]

On jsdom 30.1.0, Object.getOwnPropertySymbols(Object.getOwnPropertyDescriptors(new window.Blob())) returns an empty array - a fresh jsdom Blob instance no longer exposes its internal impl via an own Symbol property this way. So implSymbol is undefined, and blob[implSymbol] (i.e. impl in the patched code) is also undefined regardless of which property name (_buffer or _bytes) is read off it afterward. The _bytes ?? _buffer fallback only helps in a case where implSymbol correctly resolves but the field name changed - it doesn't help here, since implSymbol itself no longer resolves on 30.1.0.

Minimal, framework-free repro confirming the symbol lookup itself is what's broken (node repro.js, only needs jsdom installed):

const { JSDOM } = require('jsdom')
const window = new JSDOM().window

const implSymbol = Object.getOwnPropertySymbols(Object.getOwnPropertyDescriptors(new window.Blob()))[0]
console.log('implSymbol:', implSymbol) // undefined on jsdom 30.1.0, defined on 30.0.1

Versions: vitest@4.1.11, jsdom@30.1.0 (30.0.1 is fine), Node 24.19.0.

Sorry for the noise across repos - I'd first misattributed this to @mswjs/interceptors (mswjs/interceptors#841), then to jsdom itself (jsdom/jsdom#4361, which I'm closing now) before tracing it back here. Happy to open this as a fresh issue instead if that's preferred over reopening.

[harshit-d3v]

can reproduce this. it's not the _bytes rename this time, jsdom 30.1.0 moved the impl into a private field (#impl in lib/generated/idl/utils.js), so the getOwnPropertySymbols scan returns nothing and blob[implSymbol] is undefined. URL.createObjectURL breaks the same way.

only sync way to get the bytes now is jsdom's own implForWrapper (jsdom/lib/generated/idl/utils.js in 30.1, lib/jsdom/living/generated/utils.js before). i have a fix that tries both paths and falls back to the symbol scan, passes on 29.1.1, 30.0.1 and 30.1.0 including your Request + FormData repro, plus a test that checks the bytes actually round-trip.

@hi-ogawa #11300 touches the same function. want it added there or a separate PR once that lands?