@nitrosend/email-renderer

@nitrosend/email-renderer

The single implementation of Nitrosend email section semantics: section design JSON → MJML. Executed in two hosts from the same artifact:

• Browser canvas — renders per edit, locally, no round trips.
• Rails API (embedded V8) — delivery, preview, and library renders.

MJML → HTML compilation uses the same pinned MRML build on both sides, so output is identical by construction.

Usage

import { loadSchema, documentToMjml, renderDocumentMjml } from "@nitrosend/email-renderer";
import schema from "@nitrosend/email-renderer/schema.json";

loadSchema(schema); // once per process; or pass the /v1/my/templates/spec payload

// Canvas mode: inline theme, no mj-head (canvas hosts render head elements
// as visible components)
const canvasMjml = documentToMjml(design);

// Document mode: full MJML with mj-head (font imports, heading rule,
// mj-attributes defaults) — what the server host executes
const mjml = renderDocumentMjml(design);

design is Nitrosend's section document: { version, theme, sections: [{ type, props, styles }] }.

Schema

schema.json is a generated snapshot of the component schema (theme + style attribute registries). The source of truth is config/email_components.yml in the API; regenerate with bin/rails email:goldens:generate there.

Goldens

goldens/ locks rendering behavior:

• *.design.json — the corpus (library templates, starters, synthetics), exported by the API's golden generator.
• *.server.mjml — the Rails renderer's output for each design (the parity reference).
• *.ts.mjml — this package's locked output. npm test fails on any drift; regenerate intentionally with UPDATE_GOLDENS=1 npm test.
• DIVERGENCE.md — the tracked structural gap list between the two engines (regenerated on every test run; empty is the parity goal).

Tests

npm install
npm test