fix(node): keep multipart bytes intact when the request has an encoding set

[dinwwwh]

Summary

Multipart request bodies are no longer corrupted when something upstream calls setEncoding on the request. #131 fixed string chunks for every other body type but missed form-data, which passed the raw Node stream to Response. undici encodes string chunks as utf8, whatever encoding produced them, so:

• latin1 silently corrupted file parts: the bytes ff fe 00 80 41 arrived as c3 bf c3 be 00 c2 80 41.
• base64 and hex failed with TypeError: Failed to parse body as FormData.

Changes

• The form-data body now goes through toWebReadableStream, like the octet-stream path. It encodes string chunks back to bytes with the stream's own encoding.
• A missing content-type now reaches the parser as '' instead of the literal string undefined, as in the aws-lambda adapter. The parser still rejects it.

Testing

• The encoding tests in body.test.ts now run for utf8, latin1, base64 and hex, and include form-data. Each one sends the bytes ff fe 00 80 41 (valid text for utf8, which can't round-trip invalid bytes) as a multipart file and with the file hint, then checks the exact bytes received.
• The latin1, base64 and hex form-data tests fail without the fix.
• A new test covers form-data without a content-type.
• pnpm run check and pnpm test pass, and packages/node/src/body.ts is at 100% coverage.

🤖 Generated with Claude Code

https://claude.ai/code/session_019hbEDi4A2Q9W3mUUGrMN3U

---

Generated by Claude Code

[pkg-pr-new]

• @standard-server/hono-node-playground
• @standard-server/node-http-playground

@standard-server/aws-lambda

npm i https://pkg.pr.new/@standard-server/aws-lambda@147

@standard-server/core

npm i https://pkg.pr.new/@standard-server/core@147

@standard-server/fastify

npm i https://pkg.pr.new/@standard-server/fastify@147

@standard-server/fetch

npm i https://pkg.pr.new/@standard-server/fetch@147

@standard-server/node

npm i https://pkg.pr.new/@standard-server/node@147

@standard-server/peer

npm i https://pkg.pr.new/@standard-server/peer@147

@standard-server/shared

npm i https://pkg.pr.new/@standard-server/shared@147

commit: 1bdc3d0

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[codspeed]

Merging this PR will not alter performance

✅ 26 untouched benchmarks
⏩ 108 skipped benchmarks¹

---

_{Comparing claude/dazzling-cori-ts8kto (1bdc3d0) with main (a03d8bf)}

Footnotes

1. 108 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[pullfrog]

✅ No new issues found.

Reviewed changes

• node form-data path keeps encoded bytes — _streamToFormData now feeds Response a toWebReadableStream(stream) instead of the raw Readable, so string chunks are re-encoded with stream.readableEncoding (readableChunkToBytes) rather than utf8 by undici; missing content-type now arrives as ''.
• Encoding regression coverage — the describe.each block expands to utf8/latin1/base64/hex, the file case asserts exact bytes, a form-data case asserts field + file bytes, and a new edge case covers form-data with no content-type rejecting with TypeError.

I ran pnpm --filter @standard-server/node exec vitest run src/body.test.ts (52 passing) and pnpm run check (sherif/oxlint/oxfmt/tsc all pass). Reverting body.ts to the parent commit fails the latin1/base64/hex form-data cases, confirming the tests are discriminating. The contentType ?? '' change is behavior-preserving (new Headers({'content-type': undefined}) would have produced the literal string "undefined", which also fails formData()) and now matches the aws-lambda adapter.

  ^{｜ View workflow run ｜ Using deepseek-v4.1-flash (free via Pullfrog for OSS) ｜ 𝕏}