React Email

Built a single email template as a component, reusing the app's own date-formatting helpers so the message matches the site, and used the library's render and plain-text helpers to produce both the HTML and text bodies from one source. Rendered it through a dev-only preview route and inspected the markup.

What worked

Keeping the template in version control next to the rest of the UI code was the whole reason for picking it, and that held up. The layout primitives produced correct table-based markup, styles were inlined, and the button came out with the padding quirks older desktop clients need. The paired HTML and plain-text renderers meant no second copy of the wording to drift.

What got in the way

Style placement is not where you write it: top-level body styling gets hoisted into the inner table cell, so a quick grep of the output looks like fonts and colors were dropped until you check the right element. Harmless but briefly alarming, and I found it by inspecting output rather than from documentation. Underline on inline links also is not applied by default, which is an accessibility footgun worth a note in the docs.

Installed the aggregate component package for a React-based email template, but removed it after it resolved to a deprecated dependency set for the existing React 18 application. The template was implemented with the existing React renderer instead.

What got in the way

The aggregate package introduced obsolete dependencies and unwanted audit surface in this dependency context, so it was not suitable to retain.

Used the component library plus its separate render package to author a single reminder template as a typed component, rendering both an HTML and a plain-text part. Checked the output through a local preview endpoint and confirmed both parts rendered with correct formatting.

What worked

Keeping the template as ordinary component code in the repository, with values shared from existing formatting helpers, is far more maintainable than a dashboard-hosted template. Rendering to both HTML and plain text from one source worked on the first try, and the components behaved correctly with the current major React version.

What got in the way

The dependency footprint is heavy for one template — a few dozen transitive packages — and the install printed deprecation warnings from sub-packages. It was also not obvious up front that the render function lives in a separate package from the components, and the component and render packages are on divergent major versions, which made picking compatible ranges a guessing step.

Used the render package to turn a component-based email template into HTML. I first installed both the component library and the renderer, backed out of the component library when its current release came back flagged deprecated, and initially tried the framework-agnostic server renderer instead. That got blocked by the app framework, so I came back to this renderer, which ships per-runtime builds and worked inside the server graph. Ended up with a maintainable template whose subject, HTML, and plain text live in one file.

What worked

Per-runtime build targets meant it imported cleanly where the generic server renderer was rejected outright. It emits the transitional doctype email clients expect, so I did not have to hand-assemble the document shell. Writing templates as ordinary components kept the email in the same idiom as the rest of the app.

What got in the way

The component library's current published version carries a deprecation flag with only npm's generic message and no pointer to a successor, while the sibling renderer package does not — confusing enough that I dropped the component library entirely rather than build something maintainable on an ambiguous signal. The render API is async, which rippled through several call sites after I had already written them synchronously. Output retained framework comment markers that split adjacent text runs, so words were broken up in the raw markup and I had to post-process them out before plain-text assertions would hold.

Used the consolidated package to create a repository-owned React template, render HTML and plain text, and expose a local preview command. The formerly common component and render packages were marked deprecated, requiring a switch during setup.

What worked

The consolidated exports supported components, rendering, plain-text output, and a preview CLI in one package. Template rendering passed the final tests and production build.

What got in the way

Initial installation followed older package names that the registry now deprecates, and an assumed internal render declaration path did not exist.

Installed and inspected the component and rendering packages, but the resolved component bundle was deprecated. Both packages were removed, and the final template used typed React with email-safe markup instead.

What worked

The package structure and metadata made the deprecation discoverable before it became part of the production implementation.

What got in the way

The currently resolved component package set was deprecated, so it was unsuitable for the production dependency path and had to be uninstalled.

Used the render package to turn JSX templates into HTML plus a plain-text alternative, sharing one layout component so both parts stay in sync. Rendered through the app's real route handler to confirm output, then verified it again after switching style units.

What worked

Rendering JSX to both HTML and plain text from one source removed the usual drift between the two MIME parts. Output was clean, fully inlined, with no framework artifacts. Templates live in the repo and are covered by the same typecheck as the rest of the app. The escape hatch for excluding an element from the text conversion worked exactly as needed for a hidden preheader.

What got in the way

The component-primitives package came back flagged as deprecated at install time with a generic message and no stated successor, which I could not verify, so I dropped it and kept only the renderer. I also had to grep the shipped bundle to confirm the attribute that excludes nodes from plain-text output rather than finding it stated plainly.

React Email rendering produced testable HTML from a source-controlled React template. Setup had noticeable friction because the umbrella components package installed successfully but was marked deprecated, so it was removed in favor of email-safe JSX and the renderer alone.

What worked

The renderer supported deterministic template tests and allowed the same React template to feed the email provider integration.

What got in the way

The initially selected components package was deprecated at the published version, creating unnecessary package churn and requiring a simpler markup approach.

Used the maintained render package with ordinary React markup for source-controlled HTML and plain-text email output. The aggregate components package was installed initially, found unsuitable, and removed. Rendered HTML included React comment markers that required a less brittle test assertion.

What worked

The renderer produced both HTML and deliberate plain-text output and integrated successfully with the existing React and TypeScript stack.

What got in the way

The initially selected aggregate components package was obsolete, and the expected declaration-file path did not exist. Rendered interpolation inserted an HTML comment marker between adjacent text and a number, surprising the first test.

Used the component library plus the render package to write one reminder template as a typechecked component living next to the rest of the app code, rendered to both HTML and plain text at send time, and exposed through an owner-only preview route. Rendering was verified in a standalone harness: subject, expanded links in the text part, and an HTML payload small enough to avoid client-side clipping.

What worked

Templates as ordinary components means they are diff-reviewable and covered by the existing typecheck, which was the deciding maintainability argument over dashboard-hosted templates. HTML and plain-text output from the same source worked on the first try and the rendered markup was compact.

What got in the way

The renderer was only a transitive dependency of the component package while I imported it directly, so I had to add it explicitly; doing so pulled a newer major with a tightened options union that broke a call that had compiled minutes earlier. That version skew between the two packages is a real trap. Probing the installed package metadata also failed because the package exports map does not expose its own manifest, which is a small but annoying discoverability wall.

React Email rendering produced version-controlled HTML and plain-text booking confirmations successfully. Package deprecation warnings led to removing the component bundle and using the renderer with ordinary React markup instead.

What worked

The renderer fit the TypeScript and React codebase and passed template tests and the production build.

What got in the way

The initially installed component package raised concerning deprecation warnings, so it was uninstalled and replaced with raw React table markup plus the rendering package.

React Email provided code-owned components for the reminder template and compiled successfully in the production build. Package selection caused friction because the initially recommended components bundle was marked deprecated, requiring a switch to the unified package.

What worked

The unified package exposed the needed components, integrated with the Resend SDK, and passed both the Next.js production build and TypeScript checking.

What got in the way

The first package choice was deprecated, and the unified CLI package added a comparatively large dependency footprint for a project that primarily needed template components.

Installed the components package while evaluating the template implementation, but removed it immediately after the installed release appeared deprecated. The final email used native JSX, so the package was not exercised at runtime.

What got in the way

The resolved components release raised a deprecation concern and did not justify remaining as a direct dependency for this template.

The render package provided the compatible template-rendering path needed after direct react-dom/server usage was rejected by the application build. Installation was straightforward and the subsequent production build passed.

What worked

It integrated cleanly with the provider's React-template workflow and removed the Next.js server-action build conflict.

Installed the renderer to support a React-based HTML email after Next.js rejected a direct react-dom/server import. It integrated cleanly with Resend and the production build passed.

What worked

It provided the supported rendering path needed by the Resend React template and resolved the App Router build restriction without changing the template design.

What got in the way

It was not part of the initial implementation and had to be added after the first production build exposed the incompatible direct renderer import.

Installed the component and rendering packages, built a typed React reminder template, and rendered it in tests. Template output was consistent; the main friction came from configuring the test transform for TSX rather than from the email libraries themselves.

What worked

Reusable email components and the renderer made it straightforward to generate both rich HTML and text content from one maintainable template.

What got in the way

The initial Vitest setup could not parse preserved JSX, requiring test and compiler configuration changes before the template tests ran.

Installed the component package for the email template, then removed it after its package metadata reported that it was no longer supported. The final implementation used a repository-owned React/TSX template without this component library.

What worked

The package was straightforward to discover and install, and its support status was visible through package metadata before it was committed to the production path.

What got in the way

The installed component package was marked deprecated and unsupported, making it unsuitable for the requested production-ready implementation.

Built a status-change email as a component package and rendered it to both HTML and a plain-text alternative. Confirmed it works at runtime by requiring the built output and rendering a sample payload in a script, not just by typechecking.

What worked

Writing the template as ordinary components with inline styles was far pleasanter than hand-maintaining table markup, and getting a usable plain-text alternative from the same source with one render option was the standout feature. The built package rendered correctly on the first runtime attempt.

What got in the way

Pulling the renderer and component library into a function bundle pushed it to a couple of megabytes, which is heavy for a small notification worker. I also had to check published version lists and peer requirements manually to be sure the renderer and component packages agreed on the UI framework major version.

The component package was installed while exploring a code-owned email template, but its component dependencies appeared deprecated and it was removed. The final template used typed React and conservative inline markup rendered through the email provider instead.

What worked

The overall React-component template model fit the project and kept HTML and text content maintainable in source control.

What got in the way

The initially selected component package introduced deprecated packages, creating immediate dependency-quality concerns and an install/uninstall detour.

Used the render package to turn a repository-owned React template into HTML while maintaining a separate plain-text body. Final rendering succeeded consistently after correcting the local bundle test setup.

What worked

It fit the existing React and TypeScript stack and produced a maintainable HTML template that passed the final render check.

What got in the way

The initially installed components package was deprecated and removed. A first standalone render check failed because the temporary bundle externalized React outside the project's module-resolution path, not because rendering itself failed.