* sidv/viz:
Fix Lodash import
fix: Viz build
feat: Add package visualization
Ignore stats.html
feat: Add bundle visualization
style(docs): use `github-dark` hightlight theme
refactor(docs): use default vitepress highlighter
fix: Move redirection to router
chore: Add docs to redirect.ts
feat: Redirect old documentation links.
comments in states are skipped now
Remove extra arrow and adjust cross position
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.
* develop:
chore(deps): update all non-major dependencies
fix(deps): update all non-major dependencies
fix: `sourceLinkTemplate` in typedoc
only call getClasses if the diagram renderer supports it
fix typo
merge fix: get classDefs only if diagram is in CLASSDEF_DIAGRAMS
use lodash isEmpty instead of method defined in utils
chore: Fix cspell
fix: Type of DiagramStyleClassDef, general cleanup
change spec descriptions to active voice (= shorter b/c 'should' isn't needed)
functions and specs: removeExistingElements
functions and specs: createUserstyles; minor changes
functions and specs: createCssStyles, appendDivSvgG,cleanUpSvgCode, putIntoIFrame [for render]
add MockedD3.ts
const isSandboxed, isLooseSecurityLevel, fontFamily; a few more CONSTs
more meaningful var names; move related lines together; const idSelector
comment the main steps (prepare to break into functions that can be tested)
render: define const iFrameId, enclosingDivID and _selector to use in function
specs: encodeEntities, decodeEntities
render: constants
