--clients option to email dev and a COMPATIBILITY_EMAIL_CLIENTS environment variable to narrow which email clients trigger compatibility warnings. By default the preview still warns for gmail, apple-mail, outlook, and yahoo. Teams that only target one or two clients can now skip the noise: email dev --clients outlook,apple-mail. The CLI flag wins over the env var; an empty or fully-invalid list falls back to the defaults so warnings can't be silently switched off. Builds on #2797 by @ReemX.dir/lang on Body, an empty alt fallback on Img, role="presentation" on the Markdown table, and a <title> from Preview.--tw-* CSS variables in non-inlinable rules so Tailwind media query utilities no longer break Gmail192d82a: Add theme and utility props to <Tailwind> for Tailwind v4 CSS-first configuration. Both accept a CSS string and can be combined with the existing config prop.
import themeCss from "./theme.css?inline";
<Tailwind theme={themeCss}>
<div className="bg-brand font-display">Custom themed content</div>
</Tailwind>;
Empty strings are no-ops. The base Tailwind theme and utilities are still loaded — theme and utility layer on top.
The preview server, email export, and the caniemail compatibility check all understand the Vite-style ?inline and ?raw suffixes on CSS imports, so the pattern above works the same in your project and inside the preview UI. The compatibility check also extracts the theme and utility props (in addition to config) when analyzing your template, so any caniemail incompatibilities in CSS produced by those props will surface as warnings.
Internal note: the exported setupTailwind helper now takes { config, cssConfigs } instead of a positional TailwindConfig. Calling it with the old shape throws with a migration hint.
import() template literals so changes to runtime-resolved files trigger preview reloads.email export on projects with many templates. esbuild builds now run in batches of 10 entry points, and the render phase runs each batch of 25 templates inside a worker_threads worker so V8 isolate memory is reclaimed between batches.email build, only supporting npm
email build dependency installation includes dev dependencies<Head> is outside <Tailwind>d0a7a52: Move all components and utilities into the react-email package
All components (previously in @react-email/components or individual packages like @react-email/button) and rendering utilities (previously in @react-email/render) are now exported directly from react-email. This unifies the install and import experience into a single package.
We're going to deprecate all packages except @react-email/render and @react-email/ui, and they will not be updated anymore.
Imports from @react-email/components, @react-email/render, or individual component packages (e.g. @react-email/button) are no longer the recommended path and they will all be deprecated with the exception of @react-email/render and @react-email/editor, and render will remain exported from react-email. Consumers should import everything from react-email.
Having separate packages for components (@react-email/components), and the CLI (react-email) created unnecessary confusion, and a maintenance burden for us.
Remove @react-email/components:
npm remove @react-email/components
Update react-email, and move it over to dependencies:
npm install react-email@latest
Update your imports:
- import { Button, Html, Head, render } from "@react-email/components";
+ import { Button, Html, Head, render } from "react-email";
url.parse() with WHATWG URL API in the preview dev server.d0a7a52: Move all components and utilities into the react-email package
All components (previously in @react-email/components or individual packages like @react-email/button) and rendering utilities (previously in @react-email/render) are now exported directly from react-email. This unifies the install and import experience into a single package.
We're going to deprecate all packages except @react-email/render and @react-email/preview-server, and they will not be updated anymore.
Imports from @react-email/components, @react-email/render, or individual component packages (e.g. @react-email/button) are no longer the recommended path and they will all be deprecated with the exception of @react-email/render and @react-email/editor, and render will remain exported from react-email. Consumers should import everything from react-email.
Having separate packages for components (@react-email/components), and the CLI (react-email) created unnecessary confusion, and a maintenance burden for us.
Update your dependencies -- remove @react-email/components, keep react-email:
- npm install @react-email/components react-email @react-email/preview-server
+ npm install react-email @react-email/preview-server
Update your imports:
- import { Button, Html, Head, render } from "@react-email/components";
+ import { Button, Html, Head, render } from "react-email";
The @react-email/preview-server and @react-email/editor packages are not included in react-email
url.parse() with WHATWG URL API in the preview dev server.$HOME/.react-emailemail build always failingemail buildstyleText from node:util instead of chalkexport when without manual React importemail dev on Windowsrender versions<svg> not being flagged as incompatiblecolor-scheme: dark for the previewNodeNext-style importsrequire in email exportimport ... = require(...) syntaxemail dev not working with traversal errorrender versionsstatic directoryexport's esbuild failsdeno not working as an option for email buildnext@15.2.4next@15.2.3punycode package for the static modulesemail devemail devemail dev19cab7b: Fixes decorators causing dependency tree babel parsing to fail
14b7d1d: update socket.io/socket.io-client to 4.7.5
b68e166: Fix sharp warning when running email dev
3caaf53: Updated peer dependencies to allow for React 19 release candidated and React 19 itself
9a5fd78: fix email template preview failing with emails having spaces
d118a39: Fixes tooltip color being black for specific theming configurations
481e339: Fixes root directories being hidden when they are alone at their depth
f9483ec: Deprecated renderAsync and made render itself always async
Three reasons:
See https://github.com/resend/react-email/discussions/1144 for more info.
If you are using the old render, you will need to now treat the Promise
that comes out of it, as it is now async. If you are using renderAsync,
you can replace it with render and things should work the same.
email devemail dev2799bb4: fix email template preview failing with emails having spaces
3f67038: Deprecated renderAsync and made render itself always async
Three reasons:
See https://github.com/resend/react-email/discussions/1144 for more info.
If you are using the old render, you will need to now treat the Promise
that comes out of it, as it is now async. If you are using renderAsync,
you can replace it with render and things should work the same.
emails directoryemails directory