* 'develop' of github.com:mermaid-js/mermaid:
Use pnpm/action-setup@v2
Fix pnpm-lock by resetting it, sorry!
chore: update browsers list
Update update-browserlist.yml
Update update-browserlist.yml to install pnpm
Update update-browserlist.yml to fix deprecation and action fails
* 'develop' of github.com:mermaid-js/mermaid:
Revert "fix: render the participants in same order as they are created"
Revert "Feature/4935 subgraph title margin config option"
Update integrations-community.md (Add Codemia to the list of productivity tools using Mermaid.)
* 'master' of github.com:mermaid-js/mermaid:
add inadvertent tracking removal
update announcement bar
* 'release/10.7.0' of github.com:mermaid-js/mermaid:
* 'develop' of github.com:mermaid-js/mermaid:
chore: Minor cleanup of imperativeState
fix: replace functional approaches with oop
chore: fix autogen docs
chore(sequence): Update packages/mermaid/src/docs/syntax/sequenceDiagram.md
chore(sequence): update doc for actors/participant creation/deletion fix
chore: remove unused e2e tests file
chore: add e2e test that shows db cleanup problem
chore: add e2e test that shows db cleanup problem
fix: add imperativeState and replace sequenceDb global variables with it
* master:
add jetbrains blog post
additional updates
update latest news pages
fix addl broken link
fix link
build: use `tsx` instead of `ts-node-esm`
verbiage updates
feat: Track outbound links in plausible
update getting started page
add blog post
chore: Update promo link
docs: Holiday promo v2
Update packages/mermaid/src/docs/.vitepress/components/TopBar.vue
update announcements page
update announcement bar verbiage
* develop: (200 commits)
chore(deps): update all minor dependencies
adds corresponding change in docs/ecosystem
Adds Unison programming language to community integrations list
Fixed parser/tests
Update docs
Update classDiagram.md
Update classDiagram.md
Update docs
Update packages/mermaid/src/diagrams/class/classDb.ts
Update packages/mermaid/src/docs/syntax/classDiagram.md
Update packages/mermaid/src/diagrams/class/classDb.ts
chore(deps): update all minor dependencies
Update generics docs
Update docs
Address potential undefined
refactor: Move maxEdges out of flowchart config.
refactor: Move maxEdges out of flowchart config.
chore: Add maxEdges to secure list
Update docs
Update NiceGuy.io links in integrations-community.md
...
* develop:
Update docs
Update NiceGuy.io links in integrations-community.md
build(deps-dev): bump vite from 4.4.9 to 4.4.12
Changes to .prettierignore 1. Added 'demos/dev/**' to be ignored by Prettier. 2. Added '!/demos/dev/example.html' so that Prettier ensures no one changes the example.html in a way that doesn't obey the Prettier code formatting rules.
build: use `tsx` instead of `ts-node-esm`
fix: #5100 Add viewbox to sankey
fix: Check if parentCommit is provided
Condition of Parent Id Without Merge Commit Added
Error Hash Removed
Linting Issue Fixed
Updated gitgraph.md
Linting Issue Fixed
Documentation Modified New Ex Added
e2e test case added
Merge Conflict Resolved
Suggested Changes FOR PR DONE
documentation added, Tests Fixed
All Unit Tests Passing
Unit Test Cases Added
Parser and Logic For Parent Commit Added
1. Added 'demos/dev/**' to be ignored by Prettier.
2. Added '!/demos/dev/example.html' so that Prettier ensures no one changes the example.html in a way that doesn't obey the Prettier code formatting rules.
* develop: (47 commits)
chore(deps): update all minor dependencies
chore: Rename test
test: Add unit test for generic classname and namespace
Split type from generic class name
Referenced the PmWiki's Cookbook recipe enabling MermaidJs schematics in wiki pages
test(e2e): fix pie chart E2E tests for PR #4288
Add dummy commit to trigger GH checks
chore: Revert unnecessary export
refactor: Remove unnecessary calculations
chore: Fix computeWidth function
chore: Cleanup setupGraphViewbox
Update docs
update mermaidAPI to cleanup the text before passing to getDiagramFromText
Add test for subgraphs with title margins and edge labels
Modify margin logic to avoid creating unnecessary space in subgraph
review fixes
add test
remove unused variable
fix: clean comments in text in getDiagramFromText API so flowchart works well
chore(deps): update all minor dependencies
...
* develop: (596 commits)
chore(deps): update all minor dependencies
chore(deps): update all patch dependencies
fix: flowchart image without text
fix Types
chore: Update pnpm-lock
chore: Add tests for calculateDeltaAndAngle
fix: #5064 Handle case when line has only one point
reset the testTimeout to 5 seconds and change it directly in the test
update testTimeout from 5 seconds to 10 seconds
Update all patch dependencies
fix broken link
add latest blog post
Update all minor dependencies
Update all patch dependencies
Fix docs
Update packages/mermaid/src/docs/community/questions-and-suggestions.md
Update packages/mermaid/src/diagrams/class/classRenderer-v2.ts
update edge ids
draw top actors with lines first followed by messages
Bump GitHub workflow actions to latest versions
...
* develop:
fix broken link
add latest blog post
fix linting
fix: set proper shiki theme for light and dark modes
fix: change shiki theme to github-light
add latest blog post
add latest blog post
* master:
fix broken link
add latest blog post
fix linting
fix: set proper shiki theme for light and dark modes
fix: change shiki theme to github-light
add latest blog post
add latest blog post
* develop: (164 commits)
Update all patch dependencies
Fix docs
Update packages/mermaid/src/docs/community/questions-and-suggestions.md
Update packages/mermaid/src/diagrams/class/classRenderer-v2.ts
update edge ids
draw top actors with lines first followed by messages
Bump GitHub workflow actions to latest versions
Update docs
Documentation: clarify sentence
Fix lint
Fix typo
fix typo
Add new Atlassian integrations
chore(deps): update all patch dependencies
Update demos/sequence.html
chore: release v10.6.1
fix
fix
fix: render the participants in same order as they are created
fix(flow): fix invalid ellipseText regex
...
* develop: (155 commits)
chore(deps): update all patch dependencies
chore: release v10.6.1
fix(flow): fix invalid ellipseText regex
review fixes
Update XYChart's nav link in the docs template
add comment for ts ignore
move decodeEntities to utils
review fixes
chore(deps): update all minor dependencies
chore: Point to correct changelog
add spec
fix: getMessageAPI so it considers entity codes
chore(deps): update all patch dependencies
Update integrations-community.md
docs: upate the list of tools with native support of mermaid
Fix typo in build-docs.yml
Updated mermaid version
Limiting the number of edges that are allowed in the flowchart
Update README.md
Update README.md
...
Pre-commit lint hook had made the use of ternaries harder to read
than I'd originally intended so I introduced an additional
variable which explains what is being checked and keeps ternaries
from becoming obscured.
Based on review by @nirname. I had originally been trying
to minimise number of new arguments being passed to
rerouting check but as the branch curve check is not used
elsewhere and is part of the same rerouting check it makes
sense for them to be together.
Position information now passed to rerouting fn instead.
My focus earlier on had been on relationship to `main` branch
so this is to ensure that we have some tests that cover
relationship between a pair of branches that doesn't
include `main`.
Hypothesised that working out which branch needed checking for
overlapping commits might be missing, so added that as a
nested ternary and passed result as new argument to rerouting
check.
If commits are found on the branch which will be getting the
curve (whichever branch is lower or more to the right of main
than the other, for now), then the arrow will be rerouted.
I may refactor in a follow-up commit and I think there's scope
to simplify the logic but this is a test for now.
In these tests, a new branch is created but then a commit is made
on the main branch before the new branch gets a commit. This
important to see what happens with rerouting of arrows.
Suggested by @nirname in PR review of #4927.
Followed practice of other tests so that commit IDs are
stabilised (i.e., not randomly generated) and therefore
don't show repeatedly in Cypress diff output screenshots
Checking if branch was same as main turned out to be redundant
for now, since there don't seem to be any cases where routing
curves into main.
This fixes issue found in review by @nirname and avoids a
situation where branching from the same commit results in
unnecessary rerouting.
The function also now does an additional check to see
if source branch in overlap check is on main.
As we're no longer purely checking for an overlap and
the only use of this function is to reroute the arrows
to avoid running over commits, this more literal name
should be clearer.
On previous rewrite, I had created new functions within the
overlapping functions but these were being recreated on each
iteration of Object.some(). I moved them outside this for
clarity and so they're not recreated each iteration.
Changed argument names from commit1 and commit2 to
commitA and commitB respectively to prevent confusion
with seq number values.
Replaced Array filter method with array some method
so that as soon as one overlap is found, function is
finished.
Used Object.entries instead of Object.keys to reduce
number of variables needed and make function easier
to read.
Originally, the function was checking if any commits were on the
same branch as `commit2`, the destination commit.
However, in order to avoid a conflict, we should only need to
check whether any commits are on the same branch as `commit 1`.
Updated and moved commenting as well.
Position the tooltip centered, just below the node being hovered.
Update packages/mermaid/src/diagrams/flowchart/flowDb.js
Co-authored-by: Sidharth Vinod <sidharthv96@gmail.com>
window.scrollY is already account for which means document.body.scrollTop incorrectly offsets the tooltip vertically.
The same is not true for horizontal position.
Replace the `TimonVS/pr-labeler-action` with
`release-drafter/release-drafter` as it has an [`autolabeler`][1]
option that can autolabel PRs for us.
This should fix labeling PRs from forks,
see https://github.com/TimonVS/pr-labeler-action/issues/25.
I've kept the `.github/pr-labeler.yml` configuration file, so that
links to it from the https://mermaid.js.org website continue to work.
I've also kept everything in the same
`.github/workflows/pr-labeler.yml` GitHub Actions workflow to make the
`git diff` easier to review, and to keep the GitHub Actions permissions
the same.
[1]: ff929b5ceb/README.md (autolabeler)
* develop:
docs: Wrap email in <>
chore(dev-deps): update @typescript-eslint to v6
chore(deps): update all patch dependencies
test(e2e): wait for theme-directives.html
test(e2e): remove unused code in theme-directives
test(e2e): wait for marker_unique_id.html e2e test
Update the `@typescript-eslint/eslint-plugin` and
`@typescript-eslint/parser` plugin to v6.
The full list of changes needed can be found in the
[Announcing typescript-eslint v6 blog post][1], but the ones that
affect us are:
- Dropped support for Node.JS v14.
This isn't a big deal for us, since Mermaid uses a version of
`eslint-plugin-jsdoc` that does not support Node.JS v14 either,
see 120029913d
(chore(deps): update dependency eslint-plugin-jsdoc to v46, 2023-06-27)
- Changes to the `plugin:@typescript-eslint/recommended` configuration.
I've manually changed the following two rules to match their old
`@typescript-eslint/parser` v5 settings, to avoid turning ESLint
warnings into errors:
- `@typescript-eslint/no-explicit-any` to `warn`
- `@typescript-eslint/no-unused-vars` to `warn`
[1]: https://main--typescript-eslint.netlify.app/blog/announcing-typescript-eslint-v6
The `theme-directives.html` test currently sometimes takes a screenshot
before all of the Mermaid diagrams have completed rendering.
We can use the `urlSnapshopTest()` helper function, which waits until
a `.rendered` property exists on the page.
Co-authored-by: Sidharth Vinod <sidharthv96@gmail.com>
Sometimes, Cypress takes the screenshot for marker_unique_id.html early,
before mermaid has finished rendering the diagrams.
Fixes: 924c9e913b
Co-authored-by: Sidharth Vinod <sidharthv96@gmail.com>
* develop:
chore: Fix type in 'getLineFunctionsWithOffset'
refactor: Add getLineFunctionsWithOffset function
refactor: Move EdgeData to types
fix: PointStart marker refX
chore(deps): update all patch dependencies
refactor: Fix typings in utils.ts
chore: Add @internal to createCSSStyles
chore: Bump version
refactor: Remove unused variables
fix: #4818 support `getClasses` in external diagrams.
* develop: (31 commits)
chore: Update docs
New Mermaid Live Editor for Confluence Cloud (#4814)
Update link to Discourse theme component (#4811)
Update flowchart.md (#4810)
chore: Update docs
"CSS" instead of "css" in flowchart.md (#4797)
Update CONTRIBUTING.md
Update CONTRIBUTING.md
fix: typos (#4801)
chore: Align with convention
add additional test case
chore(deps): update all patch dependencies
chore(deps): update all minor dependencies
added test case
add sanitize text
Update docs
modifications to generic parser
improvements to parseGenericTypes
Update packages/mermaid/src/diagrams/class/svgDraw.js
return comment
...
* develop: (22 commits)
docs: Fix link
Update docs
fix(pie): align slices and legend orders
Mermaid version v10.4.0
unique batches every time, if not repeated tests end up in the same batch
Added missed .md
Increase JS heap
More tests for redirects + prettier
Fixed redirects inside vitepress, extended tests
chore: Explain redirect.ts clearly
Reverted docker compose to develop branch
Run GA
Update docs
Update docs
fix(er): bug if relationship is declared first
update latest news
Removed all n00b file names and added redirects
test(er): add cypress test on entity name alias
feat(er): use square brackets to add aliases
docs(er): add release version for entity name aliases
...
* feature/frontmatterConfig:
Update docs
docs: Add frontmatter config demos
docs: Add frontmatter config docs
fix: XSS vulnerability
chore: Minor typo fixes
chore: Add test with both frontmatter and directive
Update docs
feat: Add support for config in frontmatter
deps: Update unocss and webpack to address vulnerability.
chore: Fix type in assignWithDepth
refactor: Move `sanitizeDirective` into `addDirective`
refactor: Rename and cleanup `directiveSanitizer`
chore(deps): update all patch dependencies
ci(release-drafter): add more release notes categories
Here are the changes I made:
Removed unnecessary variables and assignments
Removed unnecessary object property assignments
Removed redundant code by consolidating similar conditionals
Removed unused parameters and default values
Simplified some conditionals with boolean expressions
Removed unused variables and imports
Extracted common code into a reusable function
By optimizing the code in these ways, we can reduce the time complexity of the code and improve its performance.
2023-04-24 12:14:40 +05:30
356 changed files with 17253 additions and 9148 deletions
- [ ] :book: have read the [contribution guidelines](https://github.com/mermaid-js/mermaid/blob/develop/CONTRIBUTING.md)
- [ ] :computer: have added necessary unit/e2e tests.
- [ ] :notebook: have added documentation. Make sure [`MERMAID_RELEASE_VERSION`](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/docs/community/development.md#3-update-documentation) is used for all new features.
- [ ] :notebook: have added documentation. Make sure [`MERMAID_RELEASE_VERSION`](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/docs/community/contributing.md#update-documentation) is used for all new features.
# This Action will scan dependency manifest files that change as part of a Pull Reqest, surfacing known-vulnerable versions of the packages declared or updated in the PR. Once installed, if the workflow run is marked as required, PRs introducing known-vulnerable packages will be blocked from merging.
# This Action will scan dependency manifest files that change as part of a Pull Request, surfacing known-vulnerable versions of the packages declared or updated in the PR. Once installed, if the workflow run is marked as required, PRs introducing known-vulnerable packages will be blocked from merging.
# Public documentation: https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review#dependency-review-enforcement
find . -mindepth 2 -type d -name "*__diff_output__*" -exec sh -c 'mv "$0"/*.png ../errors/' {} \;
- name:Upload Error snapshots
if:${{ needs.e2e.result == 'failure' }}
uses:actions/upload-artifact@v4
id:upload-artifacts
with:
name:error-snapshots
path:cypress/snapshots/**/__diff_output__/*
retention-days:10
path:errors/
- name:Notify Users
if:${{ needs.e2e.result == 'failure' }}
run:|
echo "::error title=Visual tests failed::You can view images that failed by downloading the error-snapshots artifact: ${{ steps.upload-artifacts.outputs.artifact-url }}"
Please read in detail about how to contribute documentation and code on the [Mermaid documentation site.](https://mermaid-js.github.io/mermaid/#/development)
---
# Mermaid contribution cheat-sheet
## Requirements
- [volta](https://volta.sh/) to manage node versions.
Documentation is necessary for all non bugfix/refactoring changes.
Only make changes to files that are in [`/packages/mermaid/src/docs`](packages/mermaid/src/docs)
**_DO NOT CHANGE FILES IN `/docs`_**
[Join our slack community if you want closer contact!](https://join.slack.com/t/mermaid-talk/shared_invite/enQtNzc4NDIyNzk4OTAyLWVhYjQxOTI2OTg4YmE1ZmJkY2Y4MTU3ODliYmIwOTY3NDJlYjA0YjIyZTdkMDMyZTUwOGI0NjEzYmEwODcwOTE)
Try Live Editor previews of future releases: <ahref="https://develop.git.mermaid.live/"title="Try the mermaid version from the develop branch.">Develop</a> | <ahref="https://next.git.mermaid.live/"title="Try the mermaid version from the next branch.">Next</a>
</p>
<br>
<br>
@@ -30,8 +33,8 @@ Generate diagrams from markdown-like text.
@@ -41,6 +44,22 @@ Generate diagrams from markdown-like text.
<ahref="https://mermaid-js.github.io/mermaid/landing/"><imgsrc="https://github.com/mermaid-js/mermaid/blob/master/docs/intro/img/book-banner-post-release.jpg"alt="Explore Mermaid.js in depth, with real-world examples, tips & tricks from the creator... The first official book on Mermaid is available for purchase. Check it out!"></a>
## Table of content
<details>
<summary>Expand contents</summary>
- [About](#about)
- [Examples](#examples)
- [Release](#release)
- [Related projects](#related-projects)
- [Contributors](#contributors)
- [Security and safe diagrams](#security-and-safe-diagrams)
@@ -55,12 +74,12 @@ Mermaid addresses this problem by enabling users to create easily modifiable dia
<br/>
Mermaid allows even non-programmers to easily create detailed diagrams through the [Mermaid Live Editor](https://mermaid.live/).<br/>
[Tutorials](./docs/config/Tutorials.md) has video tutorials.
Use Mermaid with your favorite applications, check out the list of [Integrations and Usages of Mermaid](./docs/ecosystem/integrations.md).
For video tutorials, visit our [Tutorials](./docs/ecosystem/tutorials.md) page.
Use Mermaid with your favorite applications, check out the list of [Integrations and Usages of Mermaid](./docs/ecosystem/integrations-community.md).
You can also use Mermaid within [GitHub](https://github.blog/2022-02-14-include-diagrams-markdown-files-mermaid/) as well many of your other favorite applications—check out the list of [Integrations and Usages of Mermaid](./docs/ecosystem/integrations.md).
You can also use Mermaid within [GitHub](https://github.blog/2022-02-14-include-diagrams-markdown-files-mermaid/) as well many of your other favorite applications—check out the list of [Integrations and Usages of Mermaid](./docs/ecosystem/integrations-community.md).
For a more detailed introduction to Mermaid and some of its more basic uses, look to the [Beginner's Guide](./docs/community/n00b-overview.md), [Usage](./docs/config/usage.md) and [Tutorials](./docs/config/Tutorials.md).
For a more detailed introduction to Mermaid and some of its more basic uses, look to the [Beginner's Guide](./docs/intro/getting-started.md), [Usage](./docs/config/usage.md) and [Tutorials](./docs/ecosystem/tutorials.md).
In our release process we rely heavily on visual regression tests using [applitools](https://applitools.com/). Applitools is a great service which has been easy to use and integrate with our tests.
@@ -165,13 +184,7 @@ class Class10 {
int id
size()
}
namespace Namespace01 {
class Class11
class Class12 {
int id
size()
}
}
```
```mermaid
@@ -191,13 +204,7 @@ class Class10 {
int id
size()
}
namespace Namespace01 {
class Class11
class Class12 {
int id
size()
}
}
```
### State diagram [<a href="https://mermaid-js.github.io/mermaid/#/stateDiagram">docs</a> - <a href="https://mermaid.live/edit#pako:eNpdkEFvgzAMhf8K8nEqpYSNthx22Xbcqcexg0sCiZQQlDhIFeK_L8A6TfXp6fOz9ewJGssFVOAJSbwr7ByadGR1n8T6evpO0vQ1uZDSekOrXGFsPqJPO6q-2-imH8f_0TeHXm50lfelsAMjnEHFY6xpMdRAUhhRQxUlFy0GTTXU_RytYeAx-AdXZB1ULWovdoCB7OXWN1CRC-Ju-r3uz6UtchGHJqDbsPygU57iysb2reoWHpyOWBINvsqypb3vFMlw3TfWZF5xiY7keC6zkpUnZIUojwW-FAVvrvn51LLnvOXHQ84Q5nn-AVtLcwk">live editor</a>]
Container(mobile, "Mobile App", "Xamarin", "Provides a limited subset of the Internet Banking functionality to customers via their mobile device.")
}
Deployment_Node(comp, "Customer's computer", "Mircosoft Windows or Apple macOS"){
Deployment_Node(comp, "Customer's computer", "Microsoft Windows or Apple macOS"){
Deployment_Node(browser, "Web Browser", "Google Chrome, Mozilla Firefox,<br/> Apple Safari or Microsoft Edge"){
Container(spa, "Single Page Application", "JavaScript and Angular", "Provides all of the Internet Banking functionality to customers via their web browser.")
title "Basic xychart with many categories with category overlap"
x-axis "this is x axis" [category1, "Lorem ipsum dolor sit amet, qui minim labore adipisicing minim sint cillum sint consectetur cupidatat.", category3, category4, category5, category6, category7]
> ## Please edit the corresponding file in [/packages/mermaid/src/docs/community/contributing.md](../../packages/mermaid/src/docs/community/contributing.md).
# Mermaid Contributing Guide
You decided to take part in the development? Welcome!
We are trying to make our guidelines for you as explicit and detailed as possible.
## Initial Setup
Initial setup consists of 3 main steps:
```mermaid
flowchart LR
source --> requirements --> setup
source[Get the Source Code]
requirements[Install the Requirements]
setup[Install Packages]
```
### Get the Source Code
In GitHub, you first [**fork a mermaid repository**](https://github.com/mermaid-js/mermaid/fork) when you are going to make changes and submit pull requests.
Then you **clone** a copy to your local development machine (e.g. where you code) to make a copy with all the files to work with.
> **💡 Tip** > [Here is a GitHub document that gives an overview of the process](https://docs.github.com/en/get-started/quickstart/fork-a-repo).
```bash
git clone git@github.com/your-fork/mermaid
```
Once you have cloned the repository onto your development machine, change into the `mermaid` project folder (the top level directory of the mermaid project repository)
```bash
cd mermaid
```
### Install Requirements
We support **development within Docker** environment along with **host setup**. You may choose it up to your preferences.
**Host**
These are the tools we use for working with the code and documentation:
- [Node.js](https://nodejs.org/en/).
- [pnpm](https://pnpm.io/) package manager.
The following commands must be sufficient enough to start with:
```bash
curl -fsSL https://get.pnpm.io/install.sh | sh -
pnpm env use --global 18
```
You may also need to reload `.shrc` or `.bashrc` afterwards.
**Docker**
[Install Docker](https://docs.docker.com/engine/install/). And that is pretty much all you need.
Optionally, to run GUI (Cypress) within Docker you will also need an X11 server installed.
You might already have it installed, so check this by running:
```bash
echo$DISPLAY
```
If the `$DISPLAY` variable is not empty, then an X11 server is running. Otherwise you may need to install one.
### Install Packages
**Host**
Install packages:
```bash
pnpm install
```
**Docker**
For development using Docker there is a self-documented `run` bash script, which provides convenient aliases for `docker compose` commands.
Make sure that `./run` script is executable:
```bash
chmod +x run
```
> **💡 Tip**
> To get detailed help simply type `./run` or `./run help`.
>
> It also has short _Development quick start guide_ embedded.
Then install packages:
```bash
./run pnpm install
```
### Verify Everything Works
This step is optional, but it helps to make sure that everything in development branch was OK before you started making any changes.
You can run the `test` script to verify that pnpm is working _and_ that the repository has been cloned correctly:
**Host**
```bash
pnpm test
```
**Docker**
```bash
./run pnpm test
```
The `test` script and others are in the top-level `package.json` file.
All tests should run successfully without any errors or failures.
> **Note**
> You might see _lint_ or _formatting_ warnings. Those are ok during this step.
## Workflow
Contributing process is very simple and strightforward:
```mermaid
flowchart LR
branch --> changes --> submit
branch[Checkout a New Branch]
changes[Make Changes]
submit[Submit a PR]
```
Mermaid uses a [Git Flow](https://guides.github.com/introduction/flow/)–inspired approach to branching.
Development is done in the `develop` branch.
```mermaid
---
config:
gitGraph:
mainBranchName: develop
---
gitGraph LR:
commit
commit
branch "docs/2910_update-guidelines" order: 1
commit
commit
commit
checkout develop
merge "docs/2910_update-guidelines"
commit
```
To prepare a new version for release the maintainers create a `release/vX.X.X` branch from `develop` for testing. Once the release happens we add a tag to the `release` branch and merge it with `master`. The live product and on-line documentation are what is in the `master` branch.
## Checkout a New Branch
> **💡 Tip**
> All new work should be based on the `develop` branch.
Make sure you have the most up-to-date version of the `develop` branch.
Check out the `develop` branch, then `fetch` or `pull` to update it:
You can always check current [configuration of labelling and branch prefixes](https://github.com/mermaid-js/mermaid/blob/develop/.github/pr-labeler.yml)
- The first part is the **type** of change: a `feature`, `bug`, `chore`, `docs`
- followed by a **slash** (`/`),which helps to group like types together in many git tools
- followed by the **issue number**, e.g. `2910`
- followed by an **underscore** (`_`)
- followed by a **short description** with dashes (`-`) or underscores (`_`) instead of spaces
If your work is specific to a single diagram type, it is a good idea to put the diagram type at the start of the description. This will help us keep release notes organized by a diagram type.
> **Note**
> A new feature described in issue 2945 that adds a new arrow type called 'florbs' to state diagrams
>
> `feature/2945_state-diagram-new-arrow-florbs`
> **💡 Tip**
> A bug described in issue 1123 that causes random ugly red text in multiple diagram types
>
> `bug/1123_fix_random_ugly_red_text`
## Contributing Code
Code is the heart of every software project. We strive to make it better. Who if not us?
### Where is the Code Located?
The core of Mermaid is located under `packages/mermaid/src`.
### Running Mermaid Locally
**Host**
```bash
pnpm run dev
```
**Docker**
```bash
./run dev
```
After starting the dev server open <http://localhost:9000> in your browser.
Now you are ready to make your changes!
### Make Changes
Have a look at <http://localhost:9000>. There is a list of demos that can be used to see and test your changes.
If you need a specific diagram, you can duplicate the `example.html` file in `/demos/dev` and add your own mermaid code to your copy.
That will be served at <http://localhost:9000/dev/your-file-name.html>.
After making code changes, the dev server will rebuild the mermaid library and automatically reload the page.
Edit files in `packages/mermaid/src` as required.
### Write Tests
Tests ensure that each function, module, or part of code does what it says it will do. This is critically important when other changes are made to ensure that existing code is not broken (no regression).
Just as important, the tests act as _specifications:_ they specify what the code does (or should do).
Whenever someone is new to a section of code, they should be able to read the tests to get a thorough understanding of what it does and why.
If you are fixing a bug, you should add tests to ensure that your code has actually fixed the bug, to specify/describe what the code is doing, and to ensure the bug doesn't happen again.
(If there had been a test for the situation, the bug never would have happened in the first place.)
You may need to change existing tests if they were inaccurate.
If you are adding a feature, you will definitely need to add tests. Depending on the size of your feature, you may need to add integration tests.
#### Unit Tests
Unit tests are tests that test a single function or module. They are the easiest to write and the fastest to run.
Unit tests are mandatory for all code except the renderers. (The renderers are tested with integration tests.)
We use [Vitest](https://vitest.dev) to run unit tests.
**Host**
You can use the following command to run the unit tests:
```sh
pnpm test
```
When writing new tests, it's easier to have the tests automatically run as you make changes. You can do this by running the following command:
```sh
pnpm test:watch
```
**Docker**
When using Docker prepend your command with `./run`:
```sh
./run pnpm test
```
#### Integration / End-to-End (E2E) Tests
These test the rendering and visual appearance of the diagrams.
This ensures that the rendering of that feature in the E2E will be reviewed in the release process going forward. Less chance that it breaks!
To start working with the E2E tests:
**Host**
- Run `pnpm dev` to start the dev server
- Start **Cypress** by running `pnpm cypress:open`
**Docker**
- Enable local connections for x11 server `xhost +local:`
- Run `./run pnpm dev` to start the dev server
- Start **Cypress** by running `./run pnpm cypress:open --project .`
The rendering tests are very straightforward to create. There is a function `imgSnapshotTest`, which takes a diagram in text form and the mermaid options, and it renders that diagram in Cypress.
When running in CI it will take a snapshot of the rendered diagram and compare it with the snapshot from last build and flag it for review if it differs.
This is what a rendering test looks like:
```js
it('should render forks and joins',()=>{
imgSnapshotTest(
`
stateDiagram
state fork_state <<fork>>
[*] --> fork_state
fork_state --> State2
fork_state --> State3
state join_state <<join>>
State2 --> join_state
State3 --> join_state
join_state --> State4
State4 --> [*]
`,
{logLevel:0}
);
});
```
<!--**_[TODO - running the tests against what is expected in development. ]_** -->
<!--**_[TODO - how to generate new screenshots]_** -->
### Update Documentation
> **💡 Tip**
> Our documentation is managed in `packages/mermaid/src/docs`. Details on how to edit is in the [documentation section](#contributing-documentation)
If the users have no way to know that things have changed, then you haven't really _fixed_ anything for the users; you've just added to making Mermaid feel broken.
Likewise, if users don't know that there is a new feature that you've implemented, it will forever remain unknown and unused.
The documentation has to be updated for users to know that things have been changed and added!
If you are adding a new feature, add `(v<MERMAID_RELEASE_VERSION>+)` in the title or description. It will be replaced automatically with the current version number when the release happens.
eg: `# Feature Name (v<MERMAID_RELEASE_VERSION>+)`
We know it can sometimes be hard to code _and_ write user documentation.
Create another issue specifically for the documentation.\
You will need to help with the PR, but definitely ask for help if you feel stuck.
When it feels hard to write stuff out, explaining it to someone and having that person ask you clarifying questions can often be 80% of the work!
When in doubt, write up and submit what you can. It can be clarified and refined later. (With documentation, something is better than nothing!)
## Contributing Documentation
If it is not in the documentation, it's like it never happened. Wouldn't that be sad? With all the effort that was put into the feature?
### Where is the Documentation Located?
> **Warning**
> DO NOT CHANGE FILES IN `/docs`
>
> The `docs` folder will be automatically generated when committing to `packages/mermaid/src/docs` and **should not** be edited manually.
Documentation is located in the [`packages/mermaid/src/docs`](https://github.com/mermaid-js/mermaid/tree/develop/packages/mermaid/src/docs) folder. Just pick the right section and start typing.
The contents of [mermaid.js.org](https://mermaid.js.org/) are based on the docs from the `master` branch. Updates committed to the `master` branch are reflected in the [Mermaid Docs](https://mermaid.js.org/) once published.
source["Edit /packages/mermaid/src/docs"] -- automatic processing--> published["View /docs which will be publised on Official Website"]
```
### Running the Documentation Website Locally
**[The mermaid documentation site](https://mermaid.js.org/) is powered by [Vitepress](https://vitepress.vuejs.org/).**
Start development server for the documentation site
**Host**
```bash
pnpm --filter mermaid run docs:dev
```
or
```bash
cd packages/mermaid
pnpm docs:dev
```
**Docker**
```bash
./run docs:dev
```
Open <http://localhost:3333/> in your browser.
### Formatting
The documentation is written in Markdown. To get acquainted with its syntax [see the GitHub Markdown help page](https://help.github.com/en/github/writing-on-github/basic-writing-and-formatting-syntax).
You can use `note`, `tip`, `warning` and `danger` in triple backticks to add a note, tip, warning or danger box.
> **‼️ Danger**
> Do not use vitepress specific markdown syntax `::: warning` as it will not be processed correctly.
Here are a few examples:
````markdown
```note
This is a note
```
```tip
This is a tip
```
```warning
This is a warning
```
```danger
This is a danger alert
```
````
> **Note**
> This is a note
> **💡 Tip**
> This is a tip
> **Warning**
> This is a warning
> **‼️ Danger**
> This is a danger alert
### Navigation
If you want to propose changes to how the documentation is _organized_, such as adding a new section or re-arranging or renaming a section, you must update the **sidebar navigation**, which is defined in [the vitepress config](../.vitepress/config.ts). The same goes to **topbar**.
### Build Docs
The content of `/docs` folder is built with Github Actions.
> **Warning**
> So as to allow automatic compilation of documentation pages you have to enable Github Actions on your fork first
## Submit your pull request
> **Note**
> Do not forget to push your changes
>
> ```bash
> git push -u origin docs/2910_update-guidelines
> ```
We make all changes via Pull Requests (PRs). Open a new one.
Right now we are not following any strict rules about naming PRs. Give it a representative title and short description. There is also a [pull request template](https://github.com/mermaid-js/mermaid/blob/develop/.github/pull_request_template.md) which will help you with it.
In case in its description contains a [magic comment](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) your PR will be automatically attached to the issue:
```markdown
Resolves #<your issue ID here>
```
## Congratulations
You have successfully submitted your improvements! What is next?
- PRs will be reviewed by active maintainers, who will provide feedback and request changes as needed.
- The maintainers will request a review from _knsv_, if necessary.
- Once the PR is approved, the maintainers will merge the PR into the `develop` branch.
- When a release is ready, the `release/x.x.x` branch will be created, extensively tested and knsv will be in charge of the release process.
> ## Please edit the corresponding file in [/packages/mermaid/src/docs/community/development.md](../../packages/mermaid/src/docs/community/development.md).
# Contributing to Mermaid
## Contents
- [Technical Requirements and Setup](#technical-requirements-and-setup)
- [npx](https://docs.npmjs.com/cli/v8/commands/npx) the packaged executor in npm. This is needed [to install pnpm.](#2-install-pnpm)
Follow [the setup steps below](#setup) to install them and verify they are working
### Setup
Follow these steps to set up the environment you need to work on code and/or documentation.
#### 1. Fork and clone the repository
In GitHub, you first _fork_ a repository when you are going to make changes and submit pull requests.
Then you _clone_ a copy to your local development machine (e.g. where you code) to make a copy with all the files to work with.
[Here is a GitHub document that gives an overview of the process.](https://docs.github.com/en/get-started/quickstart/fork-a-repo)
#### 2. Install pnpm
Once you have cloned the repository onto your development machine, change into the `mermaid` project folder so that you can install `pnpm`. You will need `npx` to install pnpm because volta doesn't support it yet.
Ex:
```bash
# Change into the mermaid directory (the top level director of the mermaid project repository)
cd mermaid
# npx is required for first install because volta does not support pnpm yet
npx pnpm install
```
#### 3. Verify Everything Is Working
Once you have installed pnpm, you can run the `test` script to verify that pnpm is working _and_ that the repository has been cloned correctly:
```bash
pnpm test
```
The `test` script and others are in the top-level `package.json` file.
All tests should run successfully without any errors or failures. (You might see _lint_ or _formatting_ "warnings"; those are ok during this step.)
#### 4. Make your changes
Now you are ready to make your changes!
Edit whichever files in `src` as required.
#### 5. See your changes
Open <http://localhost:9000> in your browser, after starting the dev server.
There is a list of demos that can be used to see and test your changes.
If you need a specific diagram, you can duplicate the `example.html` file in `/demos/dev` and add your own mermaid code to your copy.
That will be served at <http://localhost:9000/dev/your-file-name.html>.
After making code changes, the dev server will rebuild the mermaid library. You will need to reload the browser page yourself to see the changes. (PRs for auto reload are welcome!)
### Docker
If you are using docker and docker-compose, you have self-documented `run` bash script, which is a convenient alias for docker-compose commands:
```bash
./run install # npx pnpm install
./run test# pnpm test
```
## Contributing Code
The basic steps for contributing code are:
```mermaid-example
graph LR
git[1. Checkout a git branch] --> codeTest[2. Write tests and code] --> doc[3. Update documentation] --> submit[4. Submit a PR] --> review[5. Review and merge]
```
```mermaid
graph LR
git[1. Checkout a git branch] --> codeTest[2. Write tests and code] --> doc[3. Update documentation] --> submit[4. Submit a PR] --> review[5. Review and merge]
```
1. **Create** and checkout a git branch and work on your code in the branch
2. Write and update **tests** (unit and perhaps even integration (e2e) tests) (If you do TDD/BDD, the order might be different.)
3. **Let users know** that things have changed or been added in the documents! This is often overlooked, but _critical_
4. **Submit** your code as a _pull request_.
5. Maintainers will **review** your code. If there are no changes necessary, the PR will be merged. Otherwise, make the requested changes and repeat.
### 1. Checkout a git branch
Mermaid uses a [Git Flow](https://guides.github.com/introduction/flow/)–inspired approach to branching.
Development is done in the `develop` branch.
Once development is done we create a `release/vX.X.X` branch from `develop` for testing.
Once the release happens we add a tag to the `release` branch and merge it with `master`. The live product and on-line documentation are what is in the `master` branch.
**All new work should be based on the `develop` branch.**
**When you are ready to do work, always, ALWAYS:**
1. Make sure you have the most up-to-date version of the `develop` branch. (fetch or pull to update it)
2. Check out the `develop` branch
3. Create a new branch for your work. Please name the branch following our naming convention below.
We use the follow naming convention for branches:
```text
[feature | bug | chore | docs]/[issue number]_[short description using dashes ('-') or underscores ('_') instead of spaces]
```
- The first part is the **type** of change: a feature, bug, chore, or documentation change ('docs')
- followed by a _slash_ (which helps to group like types together in many git tools)
- followed by the **issue number**
- followed by an _underscore_ ('\_')
- followed by a short text description (but use dashes ('-') or underscores ('\_') instead of spaces)
If your work is specific to a single diagram type, it is a good idea to put the diagram type at the start of the description. This will help us keep release notes organized: it will help us keep changes for a diagram type together.
**Ex: A new feature described in issue 2945 that adds a new arrow type called 'florbs' to state diagrams**
`feature/2945_state-diagram-new-arrow-florbs`
**Ex: A bug described in issue 1123 that causes random ugly red text in multiple diagram types**
`bug/1123_fix_random_ugly_red_text`
### 2. Write Tests
Tests ensure that each function, module, or part of code does what it says it will do. This is critically
important when other changes are made to ensure that existing code is not broken (no regression).
Just as important, the tests act as _specifications:_ they specify what the code does (or should do).
Whenever someone is new to a section of code, they should be able to read the tests to get a thorough understanding of what it does and why.
If you are fixing a bug, you should add tests to ensure that your code has actually fixed the bug, to specify/describe what the code is doing, and to ensure the bug doesn't happen again.
(If there had been a test for the situation, the bug never would have happened in the first place.)
You may need to change existing tests if they were inaccurate.
If you are adding a feature, you will definitely need to add tests. Depending on the size of your feature, you may need to add integration tests.
#### Unit Tests
Unit tests are tests that test a single function or module. They are the easiest to write and the fastest to run.
Unit tests are mandatory all code except the renderers. (The renderers are tested with integration tests.)
We use [Vitest](https://vitest.dev) to run unit tests.
You can use the following command to run the unit tests:
```sh
pnpm test
```
When writing new tests, it's easier to have the tests automatically run as you make changes. You can do this by running the following command:
```sh
pnpm test:watch
```
#### Integration/End-to-End (e2e) tests
These test the rendering and visual appearance of the diagrams.
This ensures that the rendering of that feature in the e2e will be reviewed in the release process going forward. Less chance that it breaks!
To start working with the e2e tests:
1. Run `pnpm dev` to start the dev server
2. Start **Cypress** by running `pnpm cypress:open`.
The rendering tests are very straightforward to create. There is a function `imgSnapshotTest`, which takes a diagram in text form and the mermaid options, and it renders that diagram in Cypress.
When running in CI it will take a snapshot of the rendered diagram and compare it with the snapshot from last build and flag it for review if it differs.
This is what a rendering test looks like:
```js
it('should render forks and joins', () => {
imgSnapshotTest(
`
stateDiagram
state fork_state <<fork>>
[*] --> fork_state
fork_state --> State2
fork_state --> State3
state join_state <<join>>
State2 --> join_state
State3 --> join_state
join_state --> State4
State4 --> [*]
`,
{ logLevel: 0 }
);
cy.get('svg');
});
```
**_\[TODO - running the tests against what is expected in development. ]_**
**_\[TODO - how to generate new screenshots]_**
....
### 3. Update Documentation
If the users have no way to know that things have changed, then you haven't really _fixed_ anything for the users; you've just added to making Mermaid feel broken.
Likewise, if users don't know that there is a new feature that you've implemented, it will forever remain unknown and unused.
The documentation has to be updated to users know that things have changed and added!
If you are adding a new feature, add `(v<MERMAID_RELEASE_VERSION>+)` in the title or description. It will be replaced automatically with the current version number when the release happens.
eg: `# Feature Name (v<MERMAID_RELEASE_VERSION>+)`
We know it can sometimes be hard to code _and_ write user documentation.
Our documentation is managed in `packages/mermaid/src/docs`. Details on how to edit is in the [Contributing Documentation](#contributing-documentation) section.
Create another issue specifically for the documentation.\
You will need to help with the PR, but definitely ask for help if you feel stuck.
When it feels hard to write stuff out, explaining it to someone and having that person ask you clarifying questions can often be 80% of the work!
When in doubt, write up and submit what you can. It can be clarified and refined later. (With documentation, something is better than nothing!)
### 4. Submit your pull request
**\[TODO - PR titles should start with (fix | feat | ....)]**
We make all changes via Pull Requests (PRs). As we have many Pull Requests from developers new to Mermaid, we have put in place a process wherein _knsv, Knut Sveidqvist_ is in charge of the final release process and the active maintainers are in charge of reviewing and merging most PRs.
- PRs will be reviewed by active maintainers, who will provide feedback and request changes as needed.
- The maintainers will request a review from knsv, if necessary.
- Once the PR is approved, the maintainers will merge the PR into the `develop` branch.
- When a release is ready, the `release/x.x.x` branch will be created, extensively tested and knsv will be in charge of the release process.
**Reminder: Pull Requests should be submitted to the develop branch.**
## Contributing Documentation
**_\[TODO: This section is still a WIP. It still needs MAJOR revision.]_**
If it is not in the documentation, it's like it never happened. Wouldn't that be sad? With all the effort that was put into the feature?
The docs are located in the `packages/mermaid/src/docs` folder and are written in Markdown. Just pick the right section and start typing.
The contents of [mermaid.js.org](https://mermaid.js.org/) are based on the docs from the `master` branch.
Updates committed to the `master` branch are reflected in the [Mermaid Docs](https://mermaid.js.org/) once published.
### How to Contribute to Documentation
We are a little less strict here, it is OK to commit directly in the `develop` branch if you are a collaborator.
The documentation is located in the `packages/mermaid/src/docs` directory and organized according to relevant subfolder.
The `docs` folder will be automatically generated when committing to `packages/mermaid/src/docs` and **should not** be edited manually.
source["files in /packages/mermaid/src/docs\n(changes should be done here)"] -- automatic processing\nto generate the final documentation--> published["files in /docs\ndisplayed on the official documentation site"]
source["files in /packages/mermaid/src/docs\n(changes should be done here)"] -- automatic processing\nto generate the final documentation--> published["files in /docs\ndisplayed on the official documentation site"]
```
You can use `note`, `tip`, `warning` and `danger` in triple backticks to add a note, tip, warning or danger box.
Do not use vitepress specific markdown syntax `::: warning` as it will not be processed correctly.
````
```note
Note content
```
```tip
Tip content
```
```warning
Warning content
```
```danger
Danger content
```
````
> **Note**
> If the change is _only_ to the documentation, you can get your changes published to the site quicker by making a PR to the `master` branch.
We encourage contributions to the documentation at [packages/mermaid/src/docs in the _develop_ branch](https://github.com/mermaid-js/mermaid/tree/develop/packages/mermaid/src/docs).
**_DO NOT CHANGE FILES IN `/docs`_**
### The official documentation site
**[The mermaid documentation site](https://mermaid.js.org/) is powered by [Vitepress](https://vitepress.vuejs.org/).**
To run the documentation site locally:
1. Run `pnpm --filter mermaid run docs:dev` to start the dev server. (Or `pnpm docs:dev` inside the `packages/mermaid` directory.)
2. Open <http://localhost:3333/> in your browser.
Markdown is used to format the text, for more information about Markdown [see the GitHub Markdown help page](https://help.github.com/en/github/writing-on-github/basic-writing-and-formatting-syntax).
To edit Docs on your computer:
_\[TODO: need to keep this in sync with [check out a git branch in Contributing Code above](#1-checkout-a-git-branch) ]_
1. Create a fork of the develop branch to work on.
2. Find the Markdown file (.md) to edit in the `packages/mermaid/src/docs` directory.
3. Make changes or add new documentation.
4. Commit changes to your branch and push it to GitHub (which should create a new branch).
5. Create a Pull Request of your fork.
To edit Docs on GitHub:
1. Login to [GitHub.com](https://www.github.com).
2. Navigate to [packages/mermaid/src/docs](https://github.com/mermaid-js/mermaid/tree/develop/packages/mermaid/src/docs) in the mermaid-js repository.
3. To edit a file, click the pencil icon at the top-right of the file contents panel.
4. Describe what you changed in the **Propose file change** section, located at the bottom of the page.
5. Submit your changes by clicking the button **Propose file change** at the bottom (by automatic creation of a fork and a new branch).
6. Visit the Actions tab in Github, `https://github.com/<YourUsername>/mermaid/actions` and enable the actions for your fork. This will ensure that the documentation is built and updated in your fork.
7. Create a Pull Request of your newly forked branch by clicking the green **Create Pull Request** button.
If you want to propose changes to how the documentation is _organized_, such as adding a new section or re-arranging or renaming a section, you must update the **sidebar navigation.**
The sidebar navigation is defined in [the vitepress configuration file config.ts](../.vitepress/config.ts).
## Questions or Suggestions?
#### First search to see if someone has already asked (and hopefully been answered) or suggested the same thing.
- Search in Discussions
- Search in open Issues
- Search in closed Issues
If you find an open issue or discussion thread that is similar to your question but isn't answered, you can let us know that you are also interested in it.
Use the GitHub reactions to add a thumbs-up to the issue or discussion thread.
This helps the team know the relative interest in something and helps them set priorities and assignments.
Feel free to add to the discussion on the issue or topic.
If you can't find anything that already addresses your question or suggestion, _open a new issue:_
Log in to [GitHub.com](https://www.github.com), open or append to an issue [using the GitHub issue tracker of the mermaid-js repository](https://github.com/mermaid-js/mermaid/issues?q=is%3Aissue+is%3Aopen+label%3A%22Area%3A+Documentation%22).
### How to Contribute a Suggestion
## Last Words
Don't get daunted if it is hard in the beginning. We have a great community with only encouraging words. So, if you get stuck, ask for help and hints in the Slack forum. If you want to show off something good, show it off there.
[Join our Slack community if you want closer contact!](https://join.slack.com/t/mermaid-talk/shared_invite/enQtNzc4NDIyNzk4OTAyLWVhYjQxOTI2OTg4YmE1ZmJkY2Y4MTU3ODliYmIwOTY3NDJlYjA0YjIyZTdkMDMyZTUwOGI0NjEzYmEwODcwOTE)

> ## Please edit the corresponding file in [/packages/mermaid/src/docs/community/intro.md](../../packages/mermaid/src/docs/community/intro.md).
# Getting Started
So you want to help? That's great!

Here are a few things to get you started on the right path.
## How can I help?
```mermaid
mindmap
root)Contributing(
Development
Solving issues
Adding new diagrams
Handling pull requests
Updating tooling
Testing
Verification of fixed issues
Regression testing in connection with releases
Testing pull requests
Management
Coordinating the work
Classification and monitoring of incoming issues
```
## Join the Development
> **💡 Tip** > **Check out our** [**detailed contribution guide**](./contributing.md).
Where to start:
- You could start getting some knowledge of the code base by working on [these "good first issues"](https://github.com/mermaid-js/mermaid/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3A%22Good+first+issue%21%22+).
- You could jump right in and help us fix any of [these bugs](https://github.com/mermaid-js/mermaid/issues?q=is%3Aissue+is%3Aopen+label%3A%22Type%3A+Bug+%2F+Error%22++label%3A%22Contributor+needed%22+)!
- You could help write and [improve the documentation](https://github.com/mermaid-js/mermaid/issues?q=is%3Aissue+is%3Aopen+label%3A%22Area%3A+Documentation%22).
- You could work on a new feature! [These](https://github.com/mermaid-js/mermaid/issues?q=is%3Aissue+is%3Aopen+label%3A%22Area%3A+Development%22+label%3A%22Type%3A+Enhancement%22+label%3A%22Status%3A+Approved%22+) are some ideas!
- You could confirm the bugs in [these issues](https://github.com/mermaid-js/mermaid/issues?q=is%3Aissue+is%3Aopen+label%3A%22Status%3A+Triage%22++label%3A%22Type%3A+Bug+%2F+Error%22).
[Join our slack community if you want closer contact!](https://join.slack.com/t/mermaid-talk/shared_invite/enQtNzc4NDIyNzk4OTAyLWVhYjQxOTI2OTg4YmE1ZmJkY2Y4MTU3ODliYmIwOTY3NDJlYjA0YjIyZTdkMDMyZTUwOGI0NjEzYmEwODcwOTE)
## A Question Or a Suggestion?
> **💡 Tip** > **Have a look at** [**how to open an issue**](./questions-and-suggestions.md).
If you have faced a vulnerability [report it to us](./security.md).
## Last Words
Don't get daunted if it is hard in the beginning. We have a great community with only encouraging words. So, if you get stuck, ask for help and hints in the Slack forum. If you want to show off something good, show it off there.
[Join our Slack community if you want closer contact!](https://join.slack.com/t/mermaid-talk/shared_invite/enQtNzc4NDIyNzk4OTAyLWVhYjQxOTI2OTg4YmE1ZmJkY2Y4MTU3ODliYmIwOTY3NDJlYjA0YjIyZTdkMDMyZTUwOGI0NjEzYmEwODcwOTE)

> ## Please edit the corresponding file in [/packages/mermaid/src/docs/community/n00b-overview.md](../../packages/mermaid/src/docs/community/n00b-overview.md).
# Overview for Beginners
**Explaining with a Diagram**
A picture is worth a thousand words, a good diagram is undoubtedly worth more. They make understanding easier.
## Creating and Maintaining Diagrams
Anyone who has used Visio, or (God Forbid) Excel to make a Gantt Chart, knows how hard it is to create, edit and maintain good visualizations.
Diagrams/Charts are significant but also become obsolete/inaccurate very fast. This catch-22 hobbles the productivity of teams.
# Doc Rot in Diagrams
Doc-Rot kills diagrams as quickly as it does text, but it takes hours in a desktop application to produce a diagram.
Mermaid seeks to change using markdown-inspired syntax. The process is a quicker, less complicated, and more convenient way of going from concept to visualization.
It is a relatively straightforward solution to a significant hurdle with the software teams.
# Definition of Terms/ Dictionary
**Mermaid text definitions can be saved for later reuse and editing.**
> These are the Mermaid diagram definitions inside `<div>` tags, with the `class=mermaid`.
```html
<preclass="mermaid">
graph TD
A[Client] --> B[Load Balancer]
B --> C[Server01]
B --> D[Server02]
</pre>
```
**render**
> This is the core function of the Mermaid API. It reads all the `Mermaid Definitions` inside `div` tags and returns an SVG file, based on the definition.
**Nodes**
> These are the boxes that contain text or otherwise discrete pieces of each diagram, separated generally by arrows, except for Gantt Charts and User Journey Diagrams. They will be referred often in the instructions. Read for Diagram Specific [Syntax](../intro/n00b-syntaxReference.md)
## Advantages of using Mermaid
- Ease to generate, modify and render diagrams when you make them.
- The number of integrations and plugins it has.
- You can add it to your or companies website.
- Diagrams can be created through comments like this in a script:
## The catch-22 of Diagrams and Charts:
**Diagramming and charting is a large waste of developer's time, but not having diagrams ruins productivity.**
Mermaid solves this by reducing the time and effort required to create diagrams and charts.
Because, the text base for the diagrams allows it to be updated easily. Also, it can be made part of production scripts (and other pieces of code). So less time is spent on documenting, as a separate task.
## Catching up with Development
Being based on markdown, Mermaid can be used, not only by accomplished front-end developers, but by most computer savvy people to render diagrams, at much faster speeds.
In fact one can pick up the syntax for it quite easily from the examples given and there are many tutorials available in the internet.
## Mermaid is for everyone.
Video [Tutorials](https://mermaid.js.org/config/Tutorials.html) are also available for the mermaid [live editor](https://mermaid.live/).
Alternatively you can use Mermaid [Plug-Ins](https://mermaid-js.github.io/mermaid/#/./integrations), with tools you already use, like Google Docs.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.