Replace the dagre and dagre-d3 libraries with dagre-d3-es.
Both dagre and dagre-d3 are deprecated and unmaintained,
and haven't been updated for more than 3 years.
Since dagre-d3 still requires an old version of d3, this causes
a bunch of security warnings,
e.g. https://github.com/advisories/GHSA-36jr-mh4h-2g58
The [dagre-d3-es](https://github.com/tbo47/dagre-es) package is a fork
that contains support for `"d3": "^7.6.1"`. Also, it's ESM, so we will
hopefully get smaller bundle sizes too. The only issue is that this
fork isn't very well used (only has 3000 weekly downloads),
compared to `dagre-d3`'s 250,000 weekly downloads.
(although to be fair, a large proportion of dagre-d3's downloads
probably come from mermaid)
Since it's is a less popular package,
**I've pinned `dagre-d3-es` to `"7.0.2"` instead of `"^7.0.2"`**.
This does mean if there is a bug in `dagre-d3-es`, we will have to
manually bump it ourselves, but it also means we won't accidentally
be sending a buggy version of `dagre-d3-es` out to users in cases
something changes (it might be worth disabling renovate for this
if we're feeling paranoid!)
Sometimes, the mindmap e2e tests take a snapshot when the mindmap
SVG has been created, but hasn't yet been fully rendered.
This adds a quick check for a mindmap section root, so that the
snapshot is only taken after the mindmap diagram has started
rendering.
I was also running into JSDoc ESLint warnings, so I moved the file
into a TypeScript file to fix those warnings.
Currently, we have mindmap tests in the
cypress/integration/rendering/mermaid.spec.js which is a bit
odd. They should probably all be in the mindmap.spec.js file.
Use the `github-dark` highlight theme for fence blocks in vitepress,
instead of the default `material-palenight` theme.
This increases the contrast ratio of `#comments` from 2.75:1 to 4.43:1,
which is a lot more visible.
It still doesn't reach WCAG 2.0 level AA contrast standards,
which requires 4.5:1 as a minimum constrast ratio, but 4.43:1 is
pretty close, and we don't need to manually modify the theme's colours.
Use the default vitepress highlighter instead of making our own
highlighter using shiki.
The benefits are:
- We don't need to directly depend on shiki
- `mermaid-example` code-blocks will use the same highlighting
as other languages (e.g. `html`/`js`).
- We can control the theme from the global `vitepress` config.
- Darkmode/lightmode themes are supported
- Escaping is already handled by the default highlight function
We shouldn't pin dependencies unless we have to.
This is for two reasons:
- If a dependency has a security issue, users should be able to
easily update the dependency, before `mermaid` makes a new release
- If using `mermaid.core.js` in an app, using a dependency range
means that users can bundle less dependencies.
E.g. they won't need to bundle `lodash@4.17.y` just becasue mermaid
needs `lodash@4.17.x`.
For development/CI, our dependencies are pinned by pnpm-lock.yaml
file anyway.
pbrolin47