Conversation
|
✅ Deploy Preview for stacks ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for stackoverflow-email ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
…mail # Conflicts: # package-lock.json
…mail # Conflicts: # package-lock.json
dancormier
left a comment
There was a problem hiding this comment.
Really nice work here @abovedave. Adding stacks-email seems reasonable and I think this is looking pretty solid. I noticed a few bugs that I think shouldn't be too tough to handle
Note
I noticed a bunch of whitespace-only changes to a couple of yaml files and undid just the whitespace changes to reduce the noise.
|
|
||
| <Notice variant="info" class="s-anchors s-anchors__inherit s-anchors__underlined mt32"> | ||
| <p class="mb0">Looking for the previous version of Stacks? <a href="https://v2.stackoverflow.design/product/develop/using-stacks/">Go to the classic v2 documentation</a>.</p> | ||
| </Notice> |
There was a problem hiding this comment.
Looks much nicer this way
| .ff-stack-sans-headline, | ||
| .ff-stack-sans-headline-notch { | ||
| font-family: "Stack Sans Headline"; | ||
| font-family: "Stack Sans Headline" !important; |
There was a problem hiding this comment.
Was the heading font being overridden by something? I'm not necessarily against adding !important here but just curious about the issue.
| tokens: { | ||
| FIRST_NAME: "@Model.FirstName", | ||
| BUTTON_LABEL: "@Model.ButtonLabel", | ||
| BUTTON_URL: "@Model.ButtonText", |
There was a problem hiding this comment.
Should BUTTON_URL use @Model.ButtonText? Seems like @Model.ButtonText would be the expected text content of the button.
|
|
||
| <Select | ||
| id={`email-target-${kind}-${slug}`} | ||
| label={null} |
There was a problem hiding this comment.
Nit: this select should have an accessible name
| defineOption({ | ||
| name: "logoSrc", | ||
| type: "string", | ||
| initialValue: "/email/stack-overflow-logo.png", |
There was a problem hiding this comment.
The README describes email.html as “ready-to-send HTML”, but the default image sources are root-relative /email/… URLs. These images would likely break once sent outside the preview host.
Should we make asset URLs absolute/configurable or clarify that consumers must rewrite/package image assets before sending?
| Section( | ||
| [ | ||
| Button("primary", { | ||
| href: "[[CTA_URL]]", |
There was a problem hiding this comment.
[[CTA_URL]] doesn’t appear in the compile target token maps, so this href will remain literal in preview/.NET/Braze output. Can we either use the existing [[BUTTON_URL]] token here or add CTA_URL replacements for every target in src/lib/tokens.ts?
| - title: "Email gallery" | ||
| slug: "emails" | ||
| externalUrl: https://email.stackoverflow.design | ||
|
|

STACKS-905
Introduces
@stackoverflow/stacks-email, a new (experimental) MJML powered email package for building, previewing, documenting, and compiling Stack Overflow email templates.stacks-docsBackground
Historically, Stack Overflow's email design system lived across several separate implementations, including the monolith and external marketing tools. Since 2020, the system has had limited modernization or maintenance.
This work is part of the 2026 rebrand rollout. The goal is to create a shared source of truth for email design patterns, implementation, previewing, and downstream consumption.
We selected MJML because it is widely adopted, MIT licensed, and abstracts much of the client-specific complexity of writing production email HTML.
Overview
Components
~/packages/stacks-email/componentsAdds reusable email building blocks such as
Button,Header,Footer,Cardetc. Each defines their variants, options, tokens, and MJML render output in one place.Templates
~/packages/stacks-email/templatesAdds example and reusable template definitions including
Transactional,Newsletter,Promotional. These compose components into full MJML documents and can expose variants and props.Compile APIs
The package can be consumed in several ways:
@stackoverflow/stacks-emailPOST /api/compileThe package API and HTTP API intentionally serve different use cases.
The package API is the full in-process integration surface for trusted TypeScript consumers. It supports catalog discovery, component compilation, template compilation, renderable dispatch, and lower-level MJML compilation primitives.
The HTTP endpoint is a narrower service integration surface. It currently focuses on composing transactional emails from a validated JSON block list, then returning compiled MJML and HTML. This keeps the cross-service contract small while still enabling non-TypeScript consumers to generate branded email output without embedding the package.
Documentation
Adds a new Email section to
stacks-docs, including:Usage
As a package
As an endpoint
As static docs artifacts
@stackoverflow/stacks-email/sveltekitexports route handlers used bystacks-docsto serve precompiled email HTML, MJML, and manifest data.Compile targets
Every compile supports a target:
preview: replaces tokens with sample valuesdotnet: replaces tokens with Razor model bindingsbraze: replaces tokens with Braze/Liquid-style valuesThis allows the same email source to produce output for different downstream systems.
Notes for reviewers
Suggested review path:
packages/stacks-email/README.mdpackages/stacks-email/componentspackages/stacks-email/templatespackages/stacks-email/src/lib/pipelinepackages/stacks-email/src/lib/apipackages/stacks-email/src/routes/api/compile/+server.tspackages/stacks-docs/src/components/StacksEmailEmbed.sveltepackages/stacks-docs/src/routes/email/compiledCurrent limitations / Follow-ups