If all you want from zombie-mermaid is terminal output, you no longer need
the SVG half along for the ride. @zombie-mermaid/ascii-renderer and
@zombie-mermaid/svg-renderer are now documented, supported packages in
their own right — not just internal pieces the umbrella happens to be built
from.
What's new
Both packages ship a real README with install instructions and usage examples verified to actually run against the built package, not written from memory:
npm install @zombie-mermaid/ascii-rendererimport { renderMermaidASCII } from '@zombie-mermaid/ascii-renderer'
renderMermaidASCII('graph LR\n A --> B')Pure TypeScript, no DOM, no elkjs/SVG layout dependency pulled in — the
same renderer behind zombie-mermaid/ascii, just without the rest of the
package.
@zombie-mermaid/svg-renderer is the lower-level counterpart: the
ELK.js-backed layout engine and per-diagram-type SVG emitters behind
zombie-mermaid's renderMermaidSVG. It's aimed at custom integration
work — reusing the layout adapters, or wiring up a different dispatch layer
— rather than at "I just want SVG out," which zombie-mermaid's own
renderMermaidSVG(text) already covers more simply. It has since gained its own
front door, renderMermaidSVG(text) (tracked in
#1111, now closed).
One thing to know: elkjs is an optional peer dependency of
@zombie-mermaid/svg-renderer, and in a browser or bundler you must call
registerElk(ELK) once before rendering flowcharts, or rendering fails for
want of a layout engine. See the package README for the exact snippet. The
packages also have an engine requirement; see
#1567.
What's not changing
@zombie-mermaid/core and @zombie-mermaid/mermaid-parser stay
internal-only — they version and publish alongside everything else in this
repo's fixed changeset group, but they're not documented or supported for
standalone use. Same for @zombie-mermaid/mcp. Nothing about installing
zombie-mermaid itself changes; renderMermaidSVG and zombie-mermaid/ascii
still pull in the exact same code they always did.
This isn't a breaking change and doesn't need a migration guide — it's a new way to consume renderers that already existed, for anyone whose bundle size or dependency graph cares about not pulling in the half they don't use.
Where this came from
This was a product call, not a technical one: #622
scoped the monorepo's publish strategy, and the repo owner decided
ascii-renderer and svg-renderer were worth promoting to first-class
public packages while core, mermaid-parser, and mcp stay internal. The
docs landed in #1112.