Mermaid v10

[sidharthv96]

Breaking changes planned in v10

• Switch to ESM only for v10? #3590
• Break type of mermaid.render in v10 #3577
• Improve init function and how selector and nodes are passed. #3394
• mermaid.init is not using the config that's passed. #3406
• Configurable HTML class for initialisation #3055
• Add a config validator and organise global configs #3397

---

PS @aloisklink, we have blank issues now.

[aloisklink]

Do we know when v10 is expected?

On my side, I have a WIP that slightly updates the types of MermaidConfig Edit: added in PR #4112 without any breaking changes, so it can wait until a v10.0.1 release.

---

We may also want to remove @deprecated options:

mermaid/packages/mermaid/src/config.type.ts

Lines 6 to 9 in 0c18c03

	/** @deprecated use mermaid.registerLazyDiagrams instead */
	lazyLoadedDiagrams?: string[];
	/** @deprecated use mermaid.registerLazyDiagrams instead */
	loadExternalDiagramsAtStartup?: boolean;

PS @aloisklink, we have blank issues now.

Awesome, that makes life a bit easier for Mermaid experts!

[sidharthv96]

Can you make a PR with your changes?, I'll publish the release/10.0.0 branch soon with an RC.
Regarding timeline, the plan is to release v10 with only the breaking changes ASAP (No new features), so as soon as the linked issues are resolved.

#3397 is a major one to configs that might need some discussions on.

[aloisklink]

Can you make a PR with your changes?

My PR is at #4112. However, I made that PR without any breaking changes, so it can wait until a v10.0.1.

It should be pretty easy to add a config validator too using ajv too if #4112 gets merged (I believe this is the package that ESLint plugins use), in order to implement #3397. We can even add it to a v10.x release, if we make the config validator print warnings, then make it print errors in v11.

[Mister-Hope]

As mermaid v10 provide a async render function, can we expect a recent v11 that split mermaid to @mermaid-js/core and mermaid-js/xxx (xxx is diagrams)? This can make mermaid tree-shakable.

I can see that mindmap was splited to a sperated package, but somehow moved back, and this is not what I am expected.

We can still have a mermaid package that contains all diagrams by default, while let users to import and register diagram with @mermaid-js/core

[sidharthv96]

Please open a new issue/discussion.

I was pondering an idea to split all the new diagrams like mindmap and flowchart-elk into a separate single package (having individual packages for each diagram will affect adoption significantly).

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.

Only the people who bundle without splitting will be affected.

But let's discuss this in a new thread. Thanks!

[Mister-Hope]

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.