Separate Mermaid Updates from Obsidian

Feature requests
, , ,
1

Use case or problem

To enhance my documentations I would like to switch from regular tools to Obsidian. I always use markdown and mermaid in git but I want to use it now for more. So, to look how good some new diagrams will work for me I often test the latest mermaid versions. The problem here is that the update of mermaid depends on the update of Obsidian.

Proposed solution

So my idea would be to seperate it. Obsidian can still update in there defined cycle and mermaid can be updated by the user itself. Obsidian only needs to show on update if the user has changed the version and when not than obsidian updates mermaid to its recommended version. When the user updated mermaid than obsidian should not update the selected mermaid version.

For the user should be a section or field in the settings where he/she can enter either a URL for download a special version of mermaid or I have the possibility to choose from different versions. After the selection Obsidian should download the selected version. The official supported version from Obsidian should preselected.

I think this should automatically resolve all feature request with the request to update Mermaid to version x.y.z.

Related feature requests (optional)

2

Updating mermaid is often not just a matter of bundling a newer version of mermaid code.

An option would be to remove mermaid from core obsidian and turn it into a separate community plugin, but that’s going to traumatic.

I am going to rename this FR.

3

Obsidian v1.15.x will stop using Mermaid and start using Pele. Same syntax but different rendering engine, smaller and with no dependencies.

4

Field notes from the other side of this switch, since it’s about to land for everyone: I maintain a small native markdown editor, and we moved off bundled mermaid onto pele recently — it’s our only diagram dependency now.

The payload math checks out on our side too: about 250 KB gzip against ~2.6 MB for mermaid, and the bigger win was dropping roughly 75 MB from node_modules, since pele pulls no transitive dependencies. pele 1.6.0 has been stable for us in production.

Two things we had to build around it that core will probably want as well:

  • Keep-last-good rendering: when a diagram stops parsing mid-edit, keep showing the last version that parsed instead of a blank block. Otherwise one broken line in a diagram-heavy note keeps blanking blocks while you type.
  • A small LRU cache keyed by diagram source, so unchanged diagrams don’t re-run the engine on scroll, theme switches or edits elsewhere in the note.

The thing to watch during rollout is coverage of the mermaid long tail — that’s where “same syntax” will get stress-tested.