[pull] develop from mermaid-js:develop - #225
Merged
Merged
Conversation
The class diagram relation markers (composition, aggregation, extension,
dependency, lollipop) never set `markerUnits`, so they fell back to the SVG
default of `strokeWidth` and were scaled by the referencing edge's stroke
width.
`class/styles.js` applies `stroke-width: ${options.strokeWidth}` to
`path.relation` unconditionally, so themes that set `themeVariables.strokeWidth`
to 2 — redux, redux-dark, redux-color, redux-dark-color, neo, neo-dark — drew
these markers at twice their size. At 2x they overshoot the line-end offset from
`markerOffsets` and end up hidden behind the class box.
Only the default `classic` look was affected: `look: 'neo'` uses the `-margin`
marker variants, which already set `markerUnits="userSpaceOnUse"`, as does
`extensionStart` — which is why some markers looked correct while others did
not.
Set `markerUnits="userSpaceOnUse"` on the nine markers that lacked it, matching
what the `-margin` variants already did. These five marker families are
requested only by the class renderer, so no other diagram type is affected.
The existing neo e2e suite only exercised `look: 'neo'` and therefore never
covered the plain markers; CLASSIC-1/CLASSIC-2 close that gap.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
fix: class diagram markers no longer scale with edge stroke-width
With `look: 'neo'`, the first diagram rendered on a page with `layout: 'elk'` got its markers built from default theme variables: state diagram arrowheads stayed dark on dark themes, and the ER / requirement crow's-foot markers were drawn at the default stroke width. `@mermaid-js/layout-elk` is bundled with its own copy of mermaid, so it runs its own `config.ts` - one that never sees `mermaid.initialize()`. That copy is populated by `syncElkPackageConfig()`, which runs from `prepareLayout`, but `createCommonLayoutRenderer` calls `insertMarkers` before `prepareLayout`, so the first render reads defaults. Only the `*_neo` markers are affected, since they bake theme values into presentation attributes at creation time while the classic markers leave colour to the diagram stylesheet. Prefer the `insertMarkers` helper the host instance already passes in, as `mermaid-layout-tidy-tree` already does, so markers are always created against the initialized config. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
C4 element labels stopped wrapping in 11.17.0. The unified-shapes label helper gated wrapping on the root-level `wrap` option, which has no schema default and is therefore undefined, so the wrap width was always Infinity and long descriptions rendered on one unbroken line, growing the shape well past the configured c4.width. Gate on `c4.wrap` (schema default true) instead, which is what the legacy renderer used via getConfig().c4. The helper already computes the same wrap width the legacy path applied (216 - 2 * 20 = 176), and drawRect's Math.max already treats node.width as a minimum, so the box settles back at c4.width once the label wraps -- no sizing change is needed. Boundaries and relationships are still drawn by the legacy path, where the per-shape wrap flag is frozen at parse time, so they remain unwrapped (#7949).
fix(elk): build markers with the host instance's config
C4 element labels stopped wrapping in 11.17.0. The unified-shapes label helper gated wrapping on the root-level `wrap` option, which has no schema default and is therefore undefined, so the wrap width was always Infinity and long descriptions rendered on one unbroken line, growing the shape well past the configured c4.width. Gate on `c4.wrap` (schema default true) instead, which is what the legacy renderer used via getConfig().c4. The helper already computes the same wrap width the legacy path applied (216 - 2 * 20 = 176), and drawRect's Math.max already treats node.width as a minimum, so the box settles back at c4.width once the label wraps -- no sizing change is needed. Boundaries and relationships are still drawn by the legacy path, where the per-shape wrap flag is frozen at parse time, so they remain unwrapped (#7949).
The dev-explorer code editor failed to mount, throwing "Unrecognized extension value in extension set" from EditorState.create. Two copies of @codemirror/state were being bundled: @codemirror/language resolved to 6.6.0 alongside the root pin, while @codemirror/view and @codemirror/commands require ^6.7.0 and got 6.7.1. CodeMirror gives facets and state fields per-module identity, so the extensions built by @codemirror/language -- syntaxHighlighting() and the mermaid() language support -- were unrecognisable to the Configuration resolver that came from the other copy, and the editor never mounted. Raise the root pin to ^6.7.1. @codemirror/language declares ^6.0.0, so everything now collapses onto a single instance and the bundle drops the duplicate module. Add a lockfile guard test: nothing in lint, types, or the unit suite notices a duplicated CodeMirror instance, and it would silently come back on any lockfile churn.
Hotfix/11.17.1
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
The shared createLayoutElementGroups helper defaulted to `edges edgePath` (singular), so layouts going through createGraphWithElements emitted a different class than dagre, which passes `edgePaths` explicitly. The edge group class is part of the rendered SVG contract that downstream integrations style and query, and renaming it fails silently: no error, rules just stop matching. Restore `edgePaths` as the default, and point the flowchart, block and user journey stylesheets at `.edgePaths .path`. Those rules still used the flowchart-v1 `.edgePath` selector, which matches nothing in the v2 DOM. Resolves #8124 Co-authored-by: Knut Sveidqvist <knsv@sveido.com>
Merge back 11.17.2 (master) into develop. Conflicts were limited to three autogenerated typedoc pages under docs/config/setup/mermaid/functions/ — clearLayoutRenderState, defaultMeasureLayout and paintLayoutData. Both sides only disagreed on the "Defined in" line numbers for rendering-util/layout-algorithms/common/index.ts, and neither side matched the merged source. Resolved by regenerating rather than hand-picking a side: pnpm --filter mermaid docs:code followed by scripts/docs.cli.mts.
Swimlanes renders through createCommonLayoutRenderer, which builds its element groups with the default edgePathsClass from createLayoutElementGroups. #8125 restored that default from `edges edgePath` to `edges edgePaths`, so the spec's `g.edgePath` selector stopped matching and the theme/linkStyle assertions failed with "element(s) not found". Also drop the `path.path` alternative: v2 edge paths are classed `edge-thickness-* edge-pattern-* flowchart-link`, so there is no `.path` class to match and the union only made the selector look like it had a fallback.
agentflow renders through the shared layout pipeline, whose edge group is `g.edges.edgePaths` — dagre has always passed that class explicitly, and #8125 restored it as the createLayoutElementGroups default. The `.edgePath` selector here matched nothing, so `strokeWidth` never reached the edge. Brings agentflow in line with the flowchart, block and user journey stylesheets #8125 already corrected.
…caping or encoding' Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
Merge back 11.17.2 to develop
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )