Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions .changeset/cool-pigs-deny.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
---
'myst-common': patch
---

Added `options?: PluginOptions` to `TransformSpec` type. Enables passing configuration options to transform plugins.
8 changes: 8 additions & 0 deletions .changeset/orange-rockets-relate.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,8 @@
---
'myst-cli': patch
---

Integrated transform loading from options with proper plugin utilities.

Added mermaid transform import and configuration
Integrated mermaid transform into Typst build pipeline.
5 changes: 5 additions & 0 deletions .changeset/stale-ghosts-drum.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
---
'myst-spec-ext': patch
---

Added `label`, `identifier`, and `html_id` to `Image` type
29 changes: 29 additions & 0 deletions docs/diagrams.md
Original file line number Diff line number Diff line change
Expand Up @@ -24,3 +24,32 @@ flowchart LR
:::{note}
Both GitHub and JupyterLab ([#101](https://github.com/jupyter/enhancement-proposals/pull/101)) support the translation of a code-block ` ```mermaid ` to a mermaid diagram directly, this can also be used by default in MyST.
:::

## Rendering for Static Exports

MyST supports static rendering of Mermaid diagrams for static export formats (PDF, Word, LaTeX, Typst). This feature converts Mermaid syntax to base64-encoded SVG or PNG images during the build process, ensuring consistent rendering across all static output formats.

:::{important} Prerequisites
To use static Mermaid rendering, you need the Mermaid CLI installed:

```bash
npm install -g @mermaid-js/mermaid-cli
```

:::

:::{note .dropdown} For CI Environments

The Mermaid CLI uses Puppeteer which may require special configuration in CI environments. MyST automatically handles this by detecting the `CI` environment variable or you can manually control it:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is being handled here?

The example is a bit confusing, because CI is already set on both GH and GitLab, so user would never set it themselves.


```bash
# Automatic detection (recommended for CI)
CI=true npm run build

# Manual control
MERMAID_NO_SANDBOX=true npm run build
```
Comment on lines +45 to +51
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CI was way harder to get going than I thought. Should be automatic now though!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!


This automatically creates a Puppeteer configuration file with `--no-sandbox` flag to resolve sandbox issues in Linux CI environments.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, this answers part of my question from above. Does generating the config equate to disabling the sandbox? If so, maybe something like:

By default, Mermaid runs Puppeteer in a sandbox. However, in CI it needs to run directly in the current session. When the CI environment variable is set (which is the case for GitHub and GitLab), then myst will disable the sandbox by generating a suitable Puppeteer configuration file. You can also control this behavior explicitly with `MERMAID_DISABLE_SANDBOX=true/false`.

X_NO_Y namings don't read correctly in my head, but could be just me. Should this be PUPPETEER_DISABLE_SANDBOX or MERMAID_DISABLE_SANDBOX?


:::
Loading
Loading