Patch Changes

• #8248 3e9f40b Thanks @sidharthv96! - Support Mermaid 12 in the ZenUML plugin while retaining Mermaid 10 and 11 compatibility.

Patch Changes

• #8248 3e9f40b Thanks @sidharthv96! - Support Mermaid 12 in the tidy-tree layout package while retaining Mermaid 11 compatibility.

Mermaid 12.0.0 ships ELK as the bundled default layout engine, a new redux-color / neo default appearance, and two new diagram types: UML use case diagrams.

This is a breaking release (ES2024, Safari 17.4+, Node 22.12+). Existing flowcharts, state and class diagrams will re-lay out and recolour; add layout: dagre, theme: default and look: classic to your config to keep the old look. Full changelog below.

Major Changes

• #8213 33442fd Thanks @aloisklink! - chore!: require ES2024, Safari 17.4+, Node.JS v22.12+

  Mermaid is now built to target Safari 17.4+ and ES2024. If you need to support
  older browsers, you may need to polyfill or transpile mermaid.

  Safari 17.4+ has been chosen as the floor, as unlike Firefox/Chrome,
  older iOS devices don't get major Safari updates.

  Node.JS v22.12+ is also declared as requirement in our package.json files,
  but as mermaid requires a browser, this is mainly so we can use dependencies that
  also declare a Node.JS v22.12+ requirement, without causing issues for users when
  running npm install.

• #8155 810893c Thanks @ashishjain0512! - feat!: ELK is now bundled with mermaid and is the default layout algorithm.

  ELK previously shipped as a separate @mermaid-js/layout-elk package that sites had to install and register. It is now part of mermaid itself and registered automatically, so layout: elk — and the elk.stress, elk.force, elk.mrtree, elk.sporeOverlap, elk.box and elk.rectpacking variants — work with no setup.

  This changes how existing diagrams look. Flowchart, state, class, entity-relationship, requirement, use-case diagrams that do not specify a layout are now laid out by ELK instead of dagre. To keep the previous layout, set dagre explicitly:

  ---
  config:
    layout: dagre
  ---

  or globally, mermaid.initialize({ layout: 'dagre' }).

  Mindmap is unchanged: it keeps laying out with cose-bilkent unless a layout is explicitly requested (in the tiny build, which ships neither ELK nor cose-bilkent, it falls back to dagre).

  Other notes:

  • ELK is loaded as a separate chunk in the ESM builds, so it is only fetched when a diagram actually uses it. The single-file IIFE build (mermaid.min.js) inlines it and grows by roughly 500 kB gzipped.
  • The tiny build deliberately omits ELK to stay small, and falls back to dagre for diagrams that ask for an ELK layout. Its size is unchanged.
  • @mermaid-js/layout-elk is no longer needed on normal builds — existing mermaid.registerLayoutLoaders(elkLayouts) calls keep working and can be removed. It is still published, and remains the way to add ELK to the tiny build.
  • dist/mermaid.esm.min.mjs now contains syntax that es-module-lexer (used by Vite) rejects with content contains invalid JS syntax. Bundler users are unaffected as long as they import the mermaid package specifier, which resolves to the core build; only builds that point Vite directly at that dist file need to switch to the package specifier or the core build.
  • State diagrams now resolve their layout through the same registration check as every other diagram, so an unavailable layout falls back instead of failing to render.

  An unrecognised theme name now resolves to the default theme in name as well as in variables; previously the invalid name stayed in place while the default's variables were loaded, and every palette-aware stylesheet gates on the name. theme: 'null', the documented way to disable the pre-defined themes, is unaffected. Note that neo paints node strokes with a gradient when the theme sets useGradient, which base does; setting a custom nodeBorder on base turns the gradient off.

• #8211 a19bd08 Thanks @ashishjain0512! - Removed: the defaultRenderer option of the flowchart, class and state config sections.

  Use the top-level layout option instead:

  ---
  config:
    layout: dagre # or elk
  ---

  Why

  defaultRenderer named a rendering engine back when there was more than one. There is not.
  All of its accepted values — dagre, dagre-wrapper, dagre-d3 — had come to select the
  same unified renderer, and its elk value did nothing but set layout: elk on your behalf.
  The option's documented purpose no longer existed.

  What it still did was stranger than doing nothing. The detectors branched on whether the
  value was recognised, so a valid value routed a diagram to the modern renderer and an
  invalid one silently routed it to the legacy renderer. Since the default was always a
  valid value, the legacy class and state renderers were unreachable except by
  misconfiguring the option.

  What changes for you

  • layout selects the layout algorithm, as it already did. Nothing else does.
  • graph, classDiagram and stateDiagram always render with the unified diagram. This
    was already true for every valid configuration.
  • The legacy flowchart, class and state diagram ids are gone. flowchart-v2,
    classDiagram and stateDiagram are what detectType now returns for that syntax.
  • flowchart-elk as an explicit diagram keyword still works.

  Configuration that still sets defaultRenderer is ignored rather than rejected, so nothing
  throws — but it no longer has any effect, and diagrams that relied on
  flowchart: { defaultRenderer: 'elk' } to get an ELK layout should set layout: elk.

• #8223 6df1149 Thanks @aloisklink! - refactor!: remove layout internal exports

  Remove the
  clearLayoutRenderState, createCommonLayoutRenderer, defaultMeasureLayout, paintLayoutData functions,
  and the CommonLayout* types from Mermaid's public API.

  These functions were only used by the @mermaid-js/layout-elk package,
  which now bundles them. Removing them makes it easier to avoid major versions
  of mermaid.

Minor Changes

• #8048 7a3c1a8 Thanks @knsv-bot! - feat: add UML use case diagrams with actors, use cases, system boundaries, relationships, stereotypes, notes, JSON tables, class and style support, accessibility metadata, and business variants.

• #8073 cd48a64 Thanks @knsv-bot! - feat: defaultMeasureLayout accepts a unwrapGroupLabels option so a layout engine can ask for cluster labels to be measured at their natural width instead of the flowchart.wrappingWidth fallback.

  insertCluster paints a plain cluster label with an infinite width while the measurement pass wrapped it at 200px, so a layout that sizes compound nodes from the measured label sized them too narrow. Layouts now opt in explicitly; core no longer inspects the layout's name. Markdown cluster labels stay wrapped, since those are painted wrapped.

  The bundled ELK layout opts in, which changes the size of labelled subgraphs in ELK-laid-out diagrams. Diagrams laid out with dagre are unaffected.

• #8073 0cf3797 Thanks @knsv-bot! - feat: let a container pick its own ELK algorithm with @{ algorithm: … }, and add elk.box and elk.rectpacking to the selectable layout values.

  A subgraph carrying @{ algorithm: elk.box } is laid out with that algorithm in its own coordinate system instead of inheriting the diagram's. Supported values are elk.layered, elk.box, elk.rectpacking, elk.stress, elk.force, elk.mrtree, elk.radial, and elk.sporeOverlap; anything else is ignored with a warning rather than handed to ELK, where an unknown id would abort the layout. Containers with edges crossing their boundary fall back to the inherited algorithm, since isolated layout and cross-boundary edges are incompatible.

  Also in this release:

  • ELK cluster labels are measured unwrapped, so a compound node is sized to fit its label instead of to a 200px wrapping width. This changes the size — and therefore the layout — of existing ELK diagrams that have labelled subgraphs.
  • elk.box and elk.rectpacking place nodes but never route edges. Edges they leave unrouted now fall back to a straight line between the two node centres instead of failing the render.
  • keepEntryNodeOnTop pins a cycle's true entry rather than the first-declared node when a back-edge feeds the entry, so recursive flows read from where they actually start.

• #8193 813c766 Thanks ...

Major Changes

• #8213 33442fd Thanks @aloisklink! - chore!: require ES2024, Safari 17.4+, Node.JS v22.12+

  Mermaid is now built to target Safari 17.4+ and ES2024. If you need to support
  older browsers, you may need to polyfill or transpile mermaid.

  Safari 17.4+ has been chosen as the floor, as unlike Firefox/Chrome,
  older iOS devices don't get major Safari updates.

  Node.JS v22.12+ is also declared as requirement in our package.json files,
  but as mermaid requires a browser, this is mainly so we can use dependencies that
  also declare a Node.JS v22.12+ requirement, without causing issues for users when
  running npm install.

• #8155 810893c Thanks @ashishjain0512! - feat!: ELK is now bundled with mermaid and is the default layout algorithm.

  ELK previously shipped as a separate @mermaid-js/layout-elk package that sites had to install and register. It is now part of mermaid itself and registered automatically, so layout: elk — and the elk.stress, elk.force, elk.mrtree, elk.sporeOverlap, elk.box and elk.rectpacking variants — work with no setup.

  This changes how existing diagrams look. Flowchart, state, class, entity-relationship, requirement, use-case and agentflow diagrams that do not specify a layout are now laid out by ELK instead of dagre. To keep the previous layout, set dagre explicitly:

  ---
  config:
    layout: dagre
  ---

  or globally, mermaid.initialize({ layout: 'dagre' }).

  Mindmap is unchanged: it keeps laying out with cose-bilkent unless a layout is explicitly requested (in the tiny build, which ships neither ELK nor cose-bilkent, it falls back to dagre).

  Other notes:

  • ELK is loaded as a separate chunk in the ESM builds, so it is only fetched when a diagram actually uses it. The single-file IIFE build (mermaid.min.js) inlines it and grows by roughly 500 kB gzipped.
  • The tiny build deliberately omits ELK to stay small, and falls back to dagre for diagrams that ask for an ELK layout. Its size is unchanged.
  • @mermaid-js/layout-elk is no longer needed on normal builds — existing mermaid.registerLayoutLoaders(elkLayouts) calls keep working and can be removed. It is still published, and remains the way to add ELK to the tiny build.
  • dist/mermaid.esm.min.mjs now contains syntax that es-module-lexer (used by Vite) rejects with content contains invalid JS syntax. Bundler users are unaffected as long as they import the mermaid package specifier, which resolves to the core build; only builds that point Vite directly at that dist file need to switch to the package specifier or the core build.
  • State diagrams now resolve their layout through the same registration check as every other diagram, so an unavailable layout falls back instead of failing to render.

• #8148 8603bdd Thanks @ashishjain0512! - redux-color is now the default theme and neo the default look for ten diagram types — flowchart, swimlane, class, ER, requirement, sequence, state, use case, Venn and agentflow. Those rendered without an explicit theme and look change appearance; every other diagram type keeps default and classic. To keep the previous appearance, set both explicitly — mermaid.initialize({ theme: 'default', look: 'classic' }), or the same two keys under config in front matter.

  An unrecognised theme name now resolves to the default theme in name as well as in variables; previously the invalid name stayed in place while the default's variables were loaded, and every palette-aware stylesheet gates on the name. theme: 'null', the documented way to disable the pre-defined themes, is unaffected. Note that neo paints node strokes with a gradient when the theme sets useGradient, which base does; setting a custom nodeBorder on base turns the gradient off.

• #8211 a19bd08 Thanks @ashishjain0512! - Removed: the defaultRenderer option of the flowchart, class and state config sections.

  Use the top-level layout option instead:

  ---
  config:
    layout: dagre # or elk
  ---

  Why

  defaultRenderer named a rendering engine back when there was more than one. There is not.
  All of its accepted values — dagre, dagre-wrapper, dagre-d3 — had come to select the
  same unified renderer, and its elk value did nothing but set layout: elk on your behalf.
  The option's documented purpose no longer existed.

  What it still did was stranger than doing nothing. The detectors branched on whether the
  value was recognised, so a valid value routed a diagram to the modern renderer and an
  invalid one silently routed it to the legacy renderer. Since the default was always a
  valid value, the legacy class and state renderers were unreachable except by
  misconfiguring the option.

  What changes for you

  • layout selects the layout algorithm, as it already did. Nothing else does.
  • graph, classDiagram and stateDiagram always render with the unified diagram. This
    was already true for every valid configuration.
  • The legacy flowchart, class and state diagram ids are gone. flowchart-v2,
    classDiagram and stateDiagram are what detectType now returns for that syntax.
  • flowchart-elk as an explicit diagram keyword still works.

  Configuration that still sets defaultRenderer is ignored rather than rejected, so nothing
  throws — but it no longer has any effect, and diagrams that relied on
  flowchart: { defaultRenderer: 'elk' } to get an ELK layout should set layout: elk.

• #8223 6df1149 Thanks @aloisklink! - refactor!: remove layout internal exports

  Remove the
  clearLayoutRenderState, createCommonLayoutRenderer, defaultMeasureLayout, paintLayoutData functions,
  and the CommonLayout* types from Mermaid's public API.

  These functions were only used by the @mermaid-js/layout-elk package,
  which now bundles them. Removing them makes it easier to avoid major versions
  of mermaid.

Minor Changes

• #8048 7a3c1a8 Thanks @knsv-bot! - feat: add UML use case diagrams with actors, use cases, system boundaries, relationships, stereotypes, notes, JSON tables, class and style support, accessibility metadata, and business variants.

• #8073 0cf3797 Thanks @knsv-bot! - feat: add the agentflow-beta diagram type for describing agentic workflows — agents, the flows they run, the tasks and tools inside them, and how control and data move between them.

  agentflow-beta TB
    flow reviewer["Review Agent"]
      changes["Gather changes"]@{ shape: input }
      analyse["Analyse"]@{ shape: task }
      lint["run_linter"]@{ shape: tool }
      changes --> analyse --> lint
    end

  • flow … end containers, a global … end scope block for nodes that must stay outside their referencing flow, and connector declarations for external systems.
  • Node shapes addressed by domain-facing aliases (task, tool, input, decision, refdoc, action) via inline @{ … } metadata, and @{ view: collapsed } to fold a container down to a summary node.
  • Edge operators carry semantics: --> sequence, -.- reference, --x failure, plus the labelled-branch form.
  • getSemanticModel() projects the parsed diagram into a presentation-free semantic view for downstream consumers, and getDiagnostics() reports structured warnings with source positions.
  • A flowContainerStroke theme variable across all built-in themes, and an agentflow config namespace for spacing, padding, and title margin.

  The diagram is beta: the syntax may still change before it is declared stable.

• #8197 846fd65 Thanks @knsv-bot! - feat(agentflow): take the redux colour palette. Under redux-color and redux-dark-color, every agentflow node kind — tool, task, decision, input, refdoc, connector, action — gets its own colour from a fixed palette slot, so colour says what an element is and stays put when the diagram is edited around it. Containers cycle a counter in declaration order, the way flowchart subgraphs do, from the slots above the kind range so a container frame never matches a node inside it. A collapsed container keeps its slot. redux-dark-color carries borders but no fills, so nodes there take palette strokes over the theme's own background. Agentflow also takes redux-color and neo as its own per-diagram de...

Major Changes

• #8213 33442fd Thanks @aloisklink! - chore!: require ES2024, Safari 17.4+, Node.JS v22.12+

  Mermaid is now built to target Safari 17.4+ and ES2024. If you need to support
  older browsers, you may need to polyfill or transpile mermaid.

  Safari 17.4+ has been chosen as the floor, as unlike Firefox/Chrome,
  older iOS devices don't get major Safari updates.

  Node.JS v22.12+ is also declared as requirement in our package.json files,
  but as mermaid requires a browser, this is mainly so we can use dependencies that
  also declare a Node.JS v22.12+ requirement, without causing issues for users when
  running npm install.

Major Changes

• #8213 33442fd Thanks @aloisklink! - chore!: require ES2024, Safari 17.4+, Node.JS v22.12+

  Mermaid is now built to target Safari 17.4+ and ES2024. If you need to support
  older browsers, you may need to polyfill or transpile mermaid.

  Safari 17.4+ has been chosen as the floor, as unlike Firefox/Chrome,
  older iOS devices don't get major Safari updates.

  Node.JS v22.12+ is also declared as requirement in our package.json files,
  but as mermaid requires a browser, this is mainly so we can use dependencies that
  also declare a Node.JS v22.12+ requirement, without causing issues for users when
  running npm install.

Patch Changes

• Updated dependencies [7a3c1a8, 0cf3797, 846fd65, 33442fd, dc2e453, ce0302d, ad98070, e2aab3f, 6b79518, 30325d4, cd48a64, c3ee3c7, 1ee934d, a7831c5, 0cf3797, 0320406, 810893c, e36b883, b993915, 4e00c5c, 3f05015, d57ed55, 1fc5bb3, b979eb4, 7ee4c3f, a6ec7ff, 1246a55, 813c766, 8603bdd, 43d9fbc, 2878cf3, 16b9a7d, def4c81, 3802472, a19bd08, f5af413, a3a92ba, e691042, ba0deed, b05824a, 0ec29e9, 0d77926, 93edd72, 75e6c30, 6df1149, a31ecb7]:
  • mermaid@12.0.0

Major Changes

• #8213 33442fd Thanks @aloisklink! - chore!: require ES2024, Safari 17.4+, Node.JS v22.12+

  Mermaid is now built to target Safari 17.4+ and ES2024. If you need to support
  older browsers, you may need to polyfill or transpile mermaid.

  Safari 17.4+ has been chosen as the floor, as unlike Firefox/Chrome,
  older iOS devices don't get major Safari updates.

  Node.JS v22.12+ is also declared as requirement in our package.json files,
  but as mermaid requires a browser, this is mainly so we can use dependencies that
  also declare a Node.JS v22.12+ requirement, without causing issues for users when
  running npm install.

Patch Changes

• Updated dependencies [7a3c1a8, 0cf3797, 846fd65, 33442fd, dc2e453, ce0302d, ad98070, e2aab3f, 6b79518, 30325d4, cd48a64, c3ee3c7, 1ee934d, a7831c5, 0cf3797, 0320406, 810893c, e36b883, b993915, 4e00c5c, 3f05015, d57ed55, 1fc5bb3, b979eb4, 7ee4c3f, a6ec7ff, 1246a55, 813c766, 8603bdd, 43d9fbc, 2878cf3, 16b9a7d, def4c81, 3802472, a19bd08, f5af413, a3a92ba, e691042, ba0deed, b05824a, 0ec29e9, 0d77926, 93edd72, 75e6c30, 6df1149, a31ecb7]:
  • mermaid@12.0.0

Major Changes

• #8213 33442fd Thanks @aloisklink! - chore!: require ES2024, Safari 17.4+, Node.JS v22.12+

  Mermaid is now built to target Safari 17.4+ and ES2024. If you need to support
  older browsers, you may need to polyfill or transpile mermaid.

  Safari 17.4+ has been chosen as the floor, as unlike Firefox/Chrome,
  older iOS devices don't get major Safari updates.

  Node.JS v22.12+ is also declared as requirement in our package.json files,
  but as mermaid requires a browser, this is mainly so we can use dependencies that
  also declare a Node.JS v22.12+ requirement, without causing issues for users when
  running npm install.

Minor Changes

• #8152 d4bea0d Thanks @knsv-bot! - feat: elk.preset picks a named combination of the options that decide where nodes end up.

  Three options settle node positions, and they sit in different phases of the layout: which layer a node lands in, where it goes within that layer, and which edges get reversed to make the graph acyclic. Choosing them well means knowing all three interact; preset names the combinations worth using.

  • default — network simplex layering, balanced Brandes-Koepf placement at the top level and inside subgraphs, and depth-first cycle breaking. Balanced placement centres branches and composite-state entries; depth-first breaking gives shorter back edges on graphs that loop.
  • legacy — reproduces what earlier versions actually rendered: Brandes-Koepf placement with ELK's own greedy cycle breaking.
  • modelOrder — as depthFirst, but breaks cycles by greedy model order, which disturbs declaration order least at the cost of longer back edges.
  • depthFirst — the previous default: network simplex layering and top-level placement, Brandes-Koepf placement inside subgraphs, NONE alignment, and depth-first cycle breaking.

  ---
  config:
    layout: elk
    elk:
      preset: legacy
  ---

  Setting layeringStrategy, nodePlacementStrategy, nodePlacementAlignment or cycleBreakingStrategy explicitly overrides the preset for that one option and leaves the rest in place, so a preset is a starting point rather than a lock.

  Node placement keeps BRANDES_KOEPF, but its alignment changes from NONE to BALANCED and cycle breaking from GREEDY to DEPTH_FIRST, so existing ELK diagrams will lay out differently. preset: legacy restores the previous behaviour, and is the single switch for it — this is the net change against the last release, measured from what shipped rather than from any intermediate state.

  Subgraph contents use BRANDES_KOEPF under every preset. For modelOrder and depthFirst that is deliberately not the root's strategy: network simplex inside a frame produced routes that left the subgraph on its bounding-box corner. The two sides are tuned independently, so nodePlacementStrategy set explicitly still applies to both.

  Note that legacy uses GREEDY cycle breaking rather than the GREEDY_MODEL_ORDER the schema previously advertised. That default was declared in the schema but never listed in the shipped defaults, so it reached ELK as undefined and ELK's own default applied — legacy reproduces what was rendered, not what was documented.

• #8152 1246a55 Thanks @knsv-bot! - feat: draw line hops where ELK edges cross, controlled by elk.lineHops.

  Where two edges cross, the one that gives way is drawn with a small arc (or a visible gap) so it is clear which line passes over which. On by default; set elk.lineHops: false to draw plain crossings, or 'gap' to use gaps instead of arcs.

  ---
  config:
    layout: elk
    elk:
      lineHops: gap
  ---

  The crossing detection and both styles already existed and were used by swimlanes — this registers the afterPaint hook that lets ELK use them. An edge that takes a hop loses its corner rounding on that segment, which is the trade for a readable crossing; curved edges are skipped rather than rewritten, to avoid corrupting their geometry.

  Existing ELK diagrams with crossing edges will render differently.

• #8155 810893c Thanks @ashishjain0512! - feat: this package is now built from mermaid's own ELK implementation instead of carrying its own copy, and is only needed for Mermaid builds that ship without ELK.

  mermaid bundles ELK and registers it automatically, so most projects can drop the dependency and the registerLayoutLoaders call. The package remains published and fully functional for the tiny build (mermaid.tiny.js), which omits ELK to stay small and where registering this is the only way to get an ELK layout.

  Because it is compiled from mermaid's ELK source rather than importing the whole mermaid entry point, the published bundle no longer drags in every diagram type, parser and KaTeX: the minified ESM payload drops from roughly 1.58 MB to 728 kB gzipped. It stays self-contained, so it still loads from a CDN next to any Mermaid build with no import map.

  The rendering utilities the ELK source reaches (dompurify, katex, dayjs, dagre-d3-es) are now declared in the package's dependencies, so the npm build (.core.mjs) resolves them through your package manager — they dedupe against the host's copies and show up in audits — instead of carrying invisible inlined copies.

  Maintainers: peerDependencies.mermaid still reads ^11.0.2. It should be raised to the major that bundles ELK as part of the release.

Patch Changes

• #8152 785ca77 Thanks @knsv-bot! - fix: draw ELK subgraph frames an even distance from their contents.

  A subgraph could sit 76px from its nodes on one side and 24px on the other, with nothing visible in the gap. ELK sizes a container around everything it put inside, edges included, and an edge that runs against the flow of the layout is routed back around the outside — so a group holding one grew on whichever side that edge left by, and a group without one did not.

  The lane is real and the edge still needs it, so the space is not reclaimed. What changes is that the frame is no longer drawn around it: the frame is pulled in to an even distance from the group's own children, and the edge keeps its lane just outside, which is what an edge routed around a group should look like anyway.

  The top is left as ELK set it, since it carries the subgraph's title strip and there is no way to tell how much of that padding is the title and how much is spare.

  A frame still holds the lanes that genuinely belong to it. An edge with both endpoints inside a group never leaves it, so its lane is part of that group's interior and the frame stays drawn around it — which matters for nested groups, where a lane routed around an inner group sits inside the outer one.

  Subgraphs render tighter, and groups that used to be visibly lopsided are now even.

• #8228 e36b883 Thanks @knsv-bot! - Reserve subgraph title padding before ELK routes edges so attachments stay on the painted frame. Clip stale interior endpoints along the incoming segment, avoiding edges that run along the subgraph border.

• #8152 1befa91 Thanks @knsv-bot! - fix: edges leave diamonds, stadiums and other non-rectangular shapes without kinking.

  ELK routes to ports on a node's bounding box and always leaves one perpendicular to the side it sits on. For a rectangle that port is the attachment point; for anything else the outline is inside the box, so the attachment has to move inwards — and the direction it moves in decides whether the edge stays orthogonal.

  It used to move along the ray from the node's centre, which lands on the outline at a different offset along the side than the port ELK chose, so the opening segment came out diagonal. The attachment now walks the outline along the edge's own departure axis, staying collinear with ELK's stub: the edge leaves the outline, crosses the box, and carries on in one straight line. Rectangular nodes are unaffected.

• #8152 1348b4f Thanks @knsv-bot! - fix: an edge no longer leaves a subgraph from the frame's corner.

  elk.spacing.portsSurrounding was left at ELK's default of 0, which permits a
  port to sit exactly on a node's corner. A corner is the one boundary point with
  no side to leave from, so the edge came out of the vertex and then ran ALONG the
  frame's own edge before turning away from it. Subgraphs showed it first, because
  an edge that crosses a subgraph boundary attaches to the frame rather than t...

Major Changes

• #8213 33442fd Thanks @aloisklink! - chore!: require ES2024, Safari 17.4+, Node.JS v22.12+

  Mermaid is now built to target Safari 17.4+ and ES2024. If you need to support
  older browsers, you may need to polyfill or transpile mermaid.

  Safari 17.4+ has been chosen as the floor, as unlike Firefox/Chrome,
  older iOS devices don't get major Safari updates.

  Node.JS v22.12+ is also declared as requirement in our package.json files,
  but as mermaid requires a browser, this is mainly so we can use dependencies that
  also declare a Node.JS v22.12+ requirement, without causing issues for users when
  running npm install.

Minor Changes

• #8048 7a3c1a8 Thanks @knsv-bot! - feat: add UML use case diagrams with actors, use cases, system boundaries, relationships, stereotypes, notes, JSON tables, class and style support, accessibility metadata, and business variants.

Patch Changes

• #8125 178d7c7 Thanks @knsv-bot! - fix: restore the edgePaths class on the edge group in rendered SVG, and point the flowchart, block and user journey stylesheets at it