Add elk layout support to mermaid

[silverwind]

Fixes: #34769

This allows the user to opt-in to using elk layouts using either YAML frontmatter or %%{ init directives inside the markup code block. The default layout is not changed.

When configuration for elk layout is detect, it causes a new webpack dynamic chunk to be loaded:

If no elk layout configuration is detected, the layout is not loaded:

Before:

After:

[Copilot]

Pull request overview

Enables Mermaid diagrams rendered from Markdown to optionally use the elk layout engine (via Mermaid configuration in frontmatter or %%{ init }%% directives) without changing the default layout.

Changes:

• Adds @mermaid-js/layout-elk as a frontend dependency.
• Registers ELK layout loaders during Mermaid initialization for markup-rendered Mermaid blocks.
• Updates lockfile to include ELK-related transitive dependencies (e.g., elkjs).

Reviewed changes

Copilot reviewed 2 out of 3 changed files in this pull request and generated 2 comments.

File	Description
web_src/js/markup/mermaid.ts	Dynamically loads and registers ELK layout loaders with Mermaid before rendering diagrams.
package.json	Adds @mermaid-js/layout-elk dependency.
pnpm-lock.yaml	Locks @mermaid-js/layout-elk and new transitive dependencies.

Files not reviewed (1)

• pnpm-lock.yaml: Language not supported

Comments suppressed due to low confidence (1)

web_src/js/markup/mermaid.ts:30

• The heavy dynamic imports (now including @mermaid-js/layout-elk) happen before the early-exit check if (!pre || pre.hasAttribute('data-render-done')) return;. This means pages that re-run initMarkupCodeMermaid on already-processed markup will still pay the cost of loading/registering Mermaid/elk.

Consider moving the pre/data-render-done check (and possibly the max-length check) before performing the dynamic imports, so already-rendered blocks can bail out without extra network/work.

    mermaid.initialize({
      startOnLoad: false,
      theme: isDarkTheme() ? 'dark' : 'neutral',
      securityLevel: 'strict',
      suppressErrorRendering: true,
    });

    const pre = el.closest('pre');
    if (!pre || pre.hasAttribute('data-render-done')) return;

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[silverwind]

The suggestion from Copilot to load the layout on-demand is good, but it would require to pre-parse the mermaid source for the frontmatter block with a yaml parser, and the init block as a variant of JSON. I think this will be too complicated to add.

[silverwind]

The suggestion from Copilot to load the layout on-demand is good, but it would require to pre-parse the mermaid source for the frontmatter block with a yaml parser, and the init block as a variant of JSON. I think this will be too complicated to add.

I've actually implemented lazy loading now with a crude regex detection that works for both yaml frontmatter and json init directive.

[silverwind]

dedent test helper added because those tests were a eyesore.

[wxiaoguang]

I don't think anyone can really understand why the logic looks so strange.

[silverwind]

That's a perfectly readable function imho, but I will add a comment.

[wxiaoguang]

Quite unclear.

As a reader, I still don't understand by reading the comment:

1. Why "check config.*.defaultRender contains a elk layout" but not clearly check the chart types which support "defaultRender"
2. Why no test to cover config.otherType.defaultRender

I can accept that it checks any value's defaultRender, the prerequisite is that the comment should be clear and there should be at least one test case for config.otherType.defaultRender

If other reviewer can fully understand the logic, free free to dismiss this change request.

enough arguments