RFC: decouple resend-node from @react-email/render and react

[emiliosheinz]

Background

Several users have reported unexpected issues with @react-email/render and react appearing in their builds when using resend-node. After digging into this, we found that the root cause was that @react-email/render was listed as a direct dependency of resend-node.

As a fix, @react-email/render was made an optional peer dependency. This prevents it from being automatically installed alongside resend-node.

PR where @react-email/render was made an optional peer dependency: #532

However, even with this change, users are still running into build-time errors due to missing packages. To fix those, they need to explicitly mark the packages as external in their bundler config, which is far from ideal as it adds friction to the developer experience on the most basic usage of the package and introduces extra steps that shouldn’t be necessary just to send emails.

References:

• Bundler error in Cloudflare Workers: Cannot resolve "@react-email/render" when using resend.emails.send with html only (React not used) #587
• should not include react/@react-email/render as a dependency #309 (comment)

Proposed Change

I believe resend-node should be fully decoupled from @react-email/render and react.

Right now, resend-node is tied to a specific rendering implementation, when its responsibility should be solely to send emails. By decoupling rendering concerns, we can avoid these build-time pitfalls and make the package easier to integrate across different environments and toolchains. Instead of handling rendering internally, the package should only accept html or text values.

In the long term, this separation keeps resend-node lean and sustainable. It ensures the library remains focused on a single responsibility, making it easier to evolve and less prone to breaking changes caused by upstream dependencies. It also reduces the surface area for maintenance, since issues related to rendering would be handled where they belong, in the rendering libraries themselves.

This would be done by removing the react option from resend.emails.send and similar functions, along with any functionality that relies on it.

Example:

import { render } from '@react-email/render';
import EmailTemplate from '../components/EmailTemplate';

await resend.emails.send({
  from: 'you@example.com',
  to: 'user@gmail.com',
  replyTo: 'you@example.com',
  subject: 'hello world',
  // Decoupled approach — rendering handled entirely by the user
  html: await render(<EmailTemplate firstName="John" product="MyApp" />),
});

Open Questions

• User Delight vs. Separation of Concerns: Should resend-node continue to offer React rendering as a “convenience feature” for new users, or should it be removed entirely in favor of a clear separation? As @vcapretz pointed out, React support might feel like a small but delightful feature for those who need it.

• Breaking Change: I assume removing the react/@react-email/render integration would require a major version bump. How should we handle migration for existing users?

• Default Experience: What do you think is the right balance between a frictionless “getting started” experience and long-term maintainability/flexibility?

I’d love to hear what the community and maintainers think about this direction. Whether fully decoupling rendering is the right long-term path, if keeping React support as a convenience is worth the trade-offs, and how we could make any transition smoother for existing users. Thanks!

Other related issues

• Resend should not have a React Dependency #525
• Resend require react to be used #503
• React declaration not found in Fastify (Node.js) app #406
• Why Resend need React to work in Express?? #353
• should not include react/@react-email/render as a dependency #309
• Remove dependency on react package to make it more lightweight #243

[gabrielmfern]

definitely worth discussing, will share it with the team