Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No charts found when space between opening code fence and language name #623

Open
PizzapunkDev opened this issue Nov 29, 2023 · 3 comments

Comments

@PizzapunkDev
Copy link

Describe the bug
When there's a space between the code fence ticks ``` and the mermaid language definition, the CLI fails to find mermaid definitions and generate images. Including the space in a client-side integration, such as GFM, accepts the space and still renders the diagram as expected.

To Reproduce

Create a markdown file with whatever Mermaid chart you wish, but instead of defining it as this:

```mermaid
[chart definition goes here]
```

define it like this (noting the space between the last backtick and the mermaid language definition):

``` mermaid
[chart definition goes here]
```

and run your favourite method of generating diagrams with the CLI. It should report the error No mermaid charts found in Markdown input

For demonstration, here is GFM rendering it with the space included:

sequenceDiagram
    Alice->>John: just a single space today john?

Or indeed, with an arbitrary number of spaces, as implied by the GFM spec:

sequenceDiagram
    Alice->>John: wow its wild how many spaces i can use

Expected behavior
CLI works like the client-side rendering (Github, Gitlab tested), and accepts spaces between the code block and the language name, so that it can be detected by the CLI and rendered appropriately alongside the other options.

Tested on both latest version of Docker image and also running via npx as stated in the official documentation.

@PizzapunkDev
Copy link
Author

I suppose this line about not rolling your own markdown parser proved to be prophetic 😉

@aloisklink
Copy link
Member

I suppose this line about not rolling your own markdown parser proved to be prophetic 😉

😆

The main reason we haven't switched yet is that:

  • There are many implementations of Markdown, and we don't want to just support GFM when people might be using Pandoc markdown (or some other arbitrary Markdown spec)
  • We didn't want to make breaking changes for existing users.

However, we're planning on making a v11 release once Mermaid makes a v11 release, and we're planning on finally dropping support for Node.JS v14 & Node.JS v16. So dropping support for some more unusual Markdown implementations might be okay too.


As a temporary measure, here are two remark plugins that actually use a real markdown parser that you can use:

@PizzapunkDev
Copy link
Author

Sounds like a plan! My toolchain involves pandoc for manipulating and combining markdown files before running mermaid-cli, so for future Googlers in the same situation for now, my solution was to write a very crude Lua filter to 'process' the mermaid code blocks explicitly:

function CodeBlock(elem)
    local language = pandoc.utils.stringify(elem.classes)
    if FORMAT:match 'gfm' and language == 'mermaid' then -- don't forget to change the markdown format here or make this more generic if needed
        return {
            pandoc.RawInline('markdown', '```mermaid'), -- basically just hardcode the block without the space
            pandoc.RawBlock('markdown', elem.text),
            pandoc.RawInline('markdown', '```')
        }
    end
    return elem
end

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants