vue-email writes transactional email as Vue components

One component library for the app and the email

vue-email is a simple way to build email templates in Vue, and the pitch is the one you would expect from a Vue library in 2026.

The features list has five entries. You build email templates with Vue components. They are tested against popular email clients. Tailwind CSS is supported. Nuxt 3 has first-class support. And it is written in TypeScript.

The first and the second are the ones that matter. Building the email with the same components as the application is a genuine win for a team that would otherwise maintain a second, parallel set of templates in a different framework, and the fact that the output is tested against real email clients is the difference between a component library and a hope. Email rendering engines are the worst kind of browser, and a library that claims the templates work across them has done the part that takes the longest.

The implementation is TypeScript, the licence is MIT, and the site is vuemail.net. The last push was on 2026-04-10, and the release history shows v1.0.0 with the title Project Rewrite from 2024-06-22, after v0.8.11 and v0.8.10 in the months before that.

That release title is worth pausing on. A 1.0 that is a rewrite means the version before it and the version after it are not the same library with more features.

The stability notice is the first thing in the readme

There is an IMPORTANT block directly under the links, and it says that the project is experimental and under heavy development, and that APIs are subject to change.

That is unusual for a project with a 1.0 release, and it is worth understanding rather than skimming. The 1.0.0 is titled Project Rewrite, so the version number was reset at the same time as the internals were replaced, and the warning is about what comes after the rewrite rather than about the rewrite itself.

For an adopter, the practical meaning is that you are adopting a moving target. A component API that is subject to change is fine if you are using two or three components and reading the documentation as you go. It is a problem if you are building a design system on top of it, because the layer above you inherits the churn.

The library is also small in the way that matters, since it is a rendering and component layer rather than a delivery service. It does not send mail, it does not manage templates on a server, and it does not schedule campaigns. Whatever you use to send the message is still yours.

That separation is the main reason to consider it despite the warning, because the part that has to be right, the HTML that a mail client will render, is the part the project is testing.

Two packages, and three ways to install them

The installation section lists three package managers, and the packages are the same in each case.

# Using npm
npm install @vue-email/render @vue-email/components

# Using yarn
yarn add @vue-email/render @vue-email/components

# Using pnpm
pnpm add @vue-email/render @vue-email/components

The two package names explain the shape of the library. The components package is the set of building blocks, the button, the heading, the table and the rest, and the render package is the part that takes your template and produces the HTML to put in a message.

That split is the sensible design, because you only need the renderer at build time, where the template is turned into a string, and the components are what end up in your bundle. A project that uses a handful of components should not pay for the whole set.

The documentation links point at the site, with a page for the Nuxt and Nitro integration, and there is a release notes link to the GitHub releases. The README is otherwise short, which suggests the documentation on the site is where the detail lives.

Tailwind in email is the hard problem this library is solving

The Tailwind support is listed as a feature, and it is worth thinking about why that is not a trivial thing to offer.

Email clients do not share a rendering engine. Some of them are webkit based, some are not, and the subset of CSS they support is much smaller than a browser's. A Tailwind utility class that works in a modern browser may be ignored entirely by a client that has never heard of it, and the failure is invisible in development because the developer is looking at it in a browser.

So supporting Tailwind in email means the library has to know which utilities it can rely on and how to compile them into something that survives, which is a much larger job than reading a config file.

The repository layout supports the claim that this work is real rather than a wrapper. There is a patches/ directory and a pnpm patchedDependencies block that pins patches for postcss-css-variables, for the process package and for tailwindcss itself, at tailwindcss 3.3.2. Patching the CSS engine and the process shim to make a build tool behave in an email context is not something a thin wrapper does.

The Nuxt 3 first-class support is the other integration worth naming, because a Nuxt application is exactly the situation where you have a design system in Vue components and need the same components in a transactional email.

A Turbo and pnpm workspace with its own toolchain

The top level listing shows a monorepo built with Turborepo, and the root package manifest is the whole build system in one file.

Most of the scripts are Turbo passthroughs. Build runs turbo run build, dev runs turbo run dev in parallel with a concurrency of 25, and test, lint and clean are the same shape. The formatting is not routed through Turbo, because it is a single Prettier pass over the TypeScript, TSX and Markdown files, with a check variant for CI.

The development dependencies tell you what the toolchain is made of. Turbo at 2.0.3 is the task runner, and tsup at 8.1.0 is the bundler, with Vite at 5.2.13 for the test and dev server, Vitest at 1.6.0 for the unit tests, and happy-dom as the DOM environment, which is a reminder that a component library for email does not need a real browser to test most of its logic.

The linter is oxlint rather than ESLint, which is a newer and much faster choice, and there is a separate vitest.workspace.ts alongside vitest.config.ts, so the test projects are configured separately from the root configuration.

The package manager is pnpm at 9.1.1, and the root package is private with a version of 0.0.0, which is the correct setup for a workspace root that is never published. The packages/ directory holds the actual publishable packages, and there is a renovate.json, so the dependency updates are automated rather than manual.

Working on it, and what the release notes say

The development section is three steps, and the second one is the detail that trips people up.

Clone the repository. Enable Corepack using corepack enable. Install the dependencies using pnpm install.

Enabling Corepack is what makes the third command work with the version the project expects, because the package manager field in the root manifest pins pnpm at 9.1.1 and Corepack is the mechanism that honours that pin rather than whatever pnpm happens to be on the machine.

The two repository level scripts that matter for a contributor are the format and format:check pair, which run Prettier over the TypeScript, TSX and Markdown, and the lint and test tasks, which are Turbo passthroughs to the individual packages.

The release notes are linked from the readme, and the most recent entry is the 1.0.0 titled Project Rewrite. For anyone who used the 0.x line, that title is the thing to read before upgrading, because the components and the render API were rewritten underneath rather than extended.

The licence is MIT, with the copyright held by Vue Email and the year range starting at 2023.

Editorial conclusion

Adopt vue-email when your team already writes Vue and you want one component library to serve both the application and the transactional email, and you are prepared to track a fast moving API. Do not adopt it for a product with a long maintenance horizon, because the project states plainly that it is experimental and that APIs are subject to change. Verify first that the render package produces output your sending provider accepts, that your chosen CSS approach works inside the email clients you care about rather than only in a browser, and that the version you install is the one the documentation at vuemail.net describes.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. vue-email/vue-email on GitHub