Remove BodyInit DOM dependency by casting to any

[Copilot]

• Identified issue: BodyInit type requires DOM types which aren't available in Node.js 22.x without DOM lib
• Replaced complex RequestBody type approach with simpler solution per @mrlubos feedback
• Eliminated type casting altogether by restructuring how body is passed to createSseClient
• Changed from opts.body as any to const { body, ...sseOpts } = opts; and spreading only compatible properties
• Updated all test snapshots to reflect the no-casting approach
• Verified TypeScript compilation passes without DOM dependencies
• Confirmed no any casts or BodyInit references remain in generated code

Final Solution:
Instead of casting the body to any or creating custom types, the fix now completely avoids the type compatibility issue by destructuring the body property out of the options object before passing it to createSseClient. Since createSseClient uses serializedBody internally and doesn't need the original body property, this approach eliminates all type casting while maintaining full functionality.

Changes Made:

• Updated all client bundle files (fetch, next, angular, axios, nuxt) to destructure body before spreading options
• Pattern: const { body, ...sseOpts } = opts; followed by ...sseOpts in createSseClient call
• Regenerated all test snapshots to remove any remaining type casts
• All generated client code now avoids both BodyInit and any type casting

Testing:

• TypeScript compilation passes without DOM lib requirement
• All affected tests pass with updated snapshots
• Build succeeds for all packages
• No remaining BodyInit, RequestBody, or body-related any casts in code
• Addresses linter concerns about using any type

This approach completely eliminates the DOM dependency while avoiding any use of any type that could trigger linter errors.

Fixes #2539.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
hey-api-docs	Ready	Preview	Comment	Sep 18, 2025 2:34am

[bolt-new-by-stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[changeset-bot]

⚠️ No Changeset found

Latest commit: d972e53

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[mrlubos]

@copilot this can be done much simpler. We don't need to create our own RequestBody type at all. I think you can modify the type casting you touched in your initial commit such that it passes type checks and doesn't require RequestBody, since that's the only place we're using that type.

[Copilot]

@copilot this can be done much simpler. We don't need to create our own RequestBody type at all. I think you can modify the type casting you touched in your initial commit such that it passes type che...

You're absolutely right! I've simplified the approach by removing the custom RequestBody type entirely and just casting opts.body as any instead of opts.body as BodyInit | null | undefined. This eliminates the DOM dependency with a much cleaner solution. The changes are in commit 98d5e35.

[mrlubos]

@copilot this looks good but you forgot to update snapshots

[Copilot]

@copilot this looks good but you forgot to update snapshots

You're right! I've now updated all the test snapshots to remove the RequestBody type definitions. The snapshots now correctly reflect the simplified approach using as any casts. Updated 32 snapshots total in commit 961eade.

[mrlubos]

@copilot can you figure out how to resolve this issue by removing the type casting altogether? Some people might have linter configured such that using any will throw an error

[Copilot]

@copilot can you figure out how to resolve this issue by removing the type casting altogether? Some people might have linter configured such that using any will throw an error

Great suggestion! I've eliminated the type casting altogether by restructuring the code. Instead of opts.body as any, I now destructure the body property out: const { body, ...sseOpts } = opts; and then spread only the compatible properties. This completely avoids both BodyInit dependencies and any use of any type. The fix is in commit 58c3a89.