fix: ESM compatibility - avoid direct Response object mutation

[omarmciver]

Summary

Fixes #1429 - Response object mutation fails in ESM environments

Problem

The Fetch client template directly mutates Response objects by adding data and error properties. This works in CommonJS but fails in ESM with node-fetch v3 where Response objects are truly read-only.

Solution

Instead of mutating the Response object, this PR creates a wrapper object that:

• Contains the custom data and error properties
• Delegates all Response properties and methods to the original response
• Maintains full backward compatibility with existing code
• Works in both CommonJS and ESM environments

Changes

Modified templates/base/http-clients/fetch-http-client.ejs to create a wrapper object instead of directly mutating the Response:

// Before (fails in ESM):
const r = response as HttpResponse<T, E>;
r.data = null;
r.error = null;

// After (works everywhere):
const r = {
  data: null,
  error: null,
  // Delegate Response properties
  ok: response.ok,
  status: response.status,
  // ... etc
  // Delegate Response methods
  json: () => response.json(),
  text: () => response.text(),
  // ... etc
} as HttpResponse<T, E>;

Testing

• ✅ Created test script to verify the template generates correct code
• ✅ Tested that the fix doesn't directly mutate Response objects
• ✅ Verified wrapper object is created properly
• ✅ Confirmed backward compatibility is maintained

Breaking Changes

None - this change is fully backward compatible. The generated API clients will have the same interface and behavior, but will now work in ESM environments.

Additional Notes

This fix enables users to migrate to:

• ESM modules ("type": "module" in package.json)
• node-fetch v3 (ESM-only version)
• Native fetch in Node.js 18+

Without this fix, users need workarounds like wrapping fetch with a Proxy to make Response properties writable, which is not ideal.

[changeset-bot[bot]]

⚠️ No Changeset found

Latest commit: 4beeb028061f8ee235a5b7cd3c1e74955b9c8770

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

[smorimoto]

bugbot run

[smorimoto]

@codex review

[smorimoto]

@omarmciver Could you add a changeset?