You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Examples of types of labels causing issues in an external project:
After applying new config setting with these changes:
📏 Design Decisions
I've added an optInMarkdownLabels config setting. It defaults to false, but when enabled (either in frontmatter, or in a call to initialize), it turns off the auto-markdown processing for node labels.
The primary goal is to provide a less intrusive upgrade path from Mermaid 10 to 11. Users who encounter markdown issues in their node rendering when upgrading to Mermaid 11 could set optInMarkdownLabels to false in order restore a closer approximation of the 10.x behavior. I'm not claiming this PR will ever guarantee no rendering changes in the upgrade from 10 to 11, but it will certainly provide a fix for the Unsupported markdown issues that can be accidentally encountered during the upgrade.
There are many issues to solve before the implementation could be considered for merge. I'm sharing the early draft just as a conversation point, to see if this approach would be acceptable if the following issues were resolved.
Need to examine closer whether my new opt-in label maker effectively captures the behavior of the old 10.7 labels. This initial sketch just wraps the text in a span.
Currently, the expected double-quote-backtick delimiter is being removed before the text is sent to the label node. I haven't found where that's happening.
I've only defaulted the useHtmlLabels path, which calls markdownToHTML. I should probably update the markdownToLines path for useHtmlLabels=false as well.
No existing unit tests have been run to verify I haven't broken anything.
No new unit tests have been written to verify the new behavior.
🦋 If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.
Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.
This PR includes no changesets
When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
📑 Summary
This is a quick strawman implementation of the direction I'm proposing to resolve #6275.
Resolves #6275
Examples of types of labels causing issues in an external project:
After applying new config setting with these changes:
📏 Design Decisions
I've added an
optInMarkdownLabelsconfig setting. It defaults to false, but when enabled (either in frontmatter, or in a call to initialize), it turns off the auto-markdown processing for node labels.The primary goal is to provide a less intrusive upgrade path from Mermaid 10 to 11. Users who encounter markdown issues in their node rendering when upgrading to Mermaid 11 could set
optInMarkdownLabelsto false in order restore a closer approximation of the 10.x behavior. I'm not claiming this PR will ever guarantee no rendering changes in the upgrade from 10 to 11, but it will certainly provide a fix for theUnsupported markdownissues that can be accidentally encountered during the upgrade.There are many issues to solve before the implementation could be considered for merge. I'm sharing the early draft just as a conversation point, to see if this approach would be acceptable if the following issues were resolved.
useHtmlLabelspath, which callsmarkdownToHTML. I should probably update themarkdownToLinespath foruseHtmlLabels=falseas well.📋 Tasks
Make sure you
MERMAID_RELEASE_VERSIONis used for all new features.pnpm changesetand following the prompts. Changesets that add features should beminorand those that fix bugs should bepatch. Please prefix changeset messages withfeat:,fix:, orchore:.