Splitting mermaid packages

[sidharthv96]

          > The size difference is significant, but as all diagrams are lazy loaded now, it won't impact most users as only diagrams they use are downloaded.

Why are you saying this, as long as the input is made by user (not me), it means I have to pack all mermaid code for them. But with sperate packages, I can pack them each much more easily and do a pre-check about users input and register new diagram for them by downloading new chunks containing the diagram, also it gives me a opportunity to drop some diagram which I "do not want to have support", they will be just gone.

But with a whole package, it will probably pack into a single chunk by webpack and vite without advanced code splitting configuration and users do need to download them all before using anyone. It's pretty hacky for developers to "remove" some codes which is actually imported and used by the module entry, also not easy for noob developers to add those code spliting configuration.

Originally posted by @Mister-Hope in https://github.com/mermaid-js/mermaid/issues/4103#issuecomment-1438362515

[sidharthv96]

Why are you saying this, as long as the input is made by user (not me), it means I have to pack all mermaid code for them.

I'm not familiar with what your use case is. I was referring to users who

1. Add via script tag (static sites, docs, blogs, etc)
2. Use a bundler like vite/esbuild/webpack (live editor)

In both the cases, only the chunks that's required to render the diagram that the user inputs will be downloaded. You can see it in action at https://deploy-preview-1160--mermaidjs.netlify.app

I didn't have to do any advanced code splitting configuration for it to work. Apart from using await for render, I actually didn't have to make any changes.

Dropping in this will enable the feature in even a static web page.

    <script type="module">
      import mermaid from 'https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.esm.min.mjs';
    </script>

It's pretty hacky for developers to "remove" some codes which is actually imported and used by the module entry

Actual diagrams are not imported in the module entry right now. Only diagram loaders. The actual diagrams will only be imported once the diagram type is detected.

But with sperate packages, I can pack them each much more easily and do a pre-check about users input and register new diagram for them by downloading new chunks containing the diagram

This is automatically done now.

---

That being said, In case there are valid usecases that help from separate packages, we're open for discussions.

[Mister-Hope]

I will explain more here:

Lines like this in a single package is not guaranteed to be split into different chunks while packing. E.g.: they may be just all packed in to a "vendor" chunk if mermaid is referenced in multiple places. The problem with it is that the bundler actually don't know the inline import file is "optional" or something just "lazyloading", for the second one, as far as I know webpack split chunking logic will infect this as it has a minChunkSize option, due to loading a whole chunk through network may be a lot faster then loading a brunch of small chunks. CDN usage is fine, but bundler is absolutely not.

The best thing to do this is allowing people to import each diagram with their needs if they want, while provide a auto loader containing the above lines and publish a whole package.

Tha's why I am requesting splitting to:

• @mermaid-js/core: core apis:
• @mermaid-js/helper: wrapper on packges which memaid rely on
• @mermaid-js/utils (or something similar): Including helper package for diagrams
• @mermaid-js/xxx (xxx is diagram name)
• mermaid: a package providing a entry for node importing all diagrams with package name, and a packed version of cdn with chunks, and maybe a full file with inlineDynamicImport: true to output a single file

[aloisklink]

• @mermaid-js/core: core apis:
• @mermaid-js/helper: wrapper on packages which mermaid rely on
• @mermaid-js/utils (or something similar): Including helper package for diagrams
• @mermaid-js/xxx (xxx is diagram name)
• mermaid: a package providing a entry for node importing all diagrams with package name, and a packed version of cdn with chunks, and maybe a full file with inlineDynamicImport: true to output a single file

This is actually a thought I've had myself too! My only issue is the maintainer's time, as it may be hard to re-arrange everything to all these different packages, and update all the release scripts to publish all these versions at once (and of course, all the documentation changes we'd need to make too).

Other benefits I see:

• It's easier to create custom Mermaid diagrams (you can easily just extend @mermaid-js/utils)
• It's easier for the core Mermaid team to create alpha/beta diagrams (like @mermaid-js/mermaid-mindmaps)
• It's easier for advanced users to remove diagrams they don't want to use in their website. (e.g. if the new flowchart-elk diagrams use up a lot of bundle space, they don't need to be included)
• Extra work: If we publish a vA.B.D release in @mermaid-js/core, we can keep @mermaid-js/xxx diagrams using vA.B.c if they haven't changed (e.g. how d3 uses a different version compared to d3-array and other d3-* packages.

[Yokozuna59]

Another benefit:

• have an overview of the most commonly used diagrams by seeing the number of downloads of each one.

---

But I'm a bit concerned about permissions; if someone is going to create a new diagram in this repo, he has to give us some permissions to this package so we can maintain it and publish updates.