GitHub/mermaid
1
0
Fork 0
mirror of https://github.com/mermaid-js/mermaid.git synced 2025-01-14 06:43:25 +08:00
Code Issues Projects Releases Wiki Activity

format .md files

Browse Source
This commit is contained in:
Ashley Engelund (weedySeaDragon @ github) 2022-11-17 16:51:23 -08:00
parent b51759d36e
commit 69526402e2
3 changed files with 259 additions and 63 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

246
docs/community/development.md
View File

@ -4,7 +4,17 @@
>
> ## Please edit the corresponding file in [/packages/mermaid/src/docs/community/development.md](../../packages/mermaid/src/docs/community/development.md).
# Development and Contribution 🙌
# Contributing to Mermaid
## Contents
- [Technical Requirements and Setup](#technical-requirements-and-setup)
- [Contributing Code](#contributing-code)
- [Contributing Documentation](#contributing-documentation)
- [Questions or Suggestions?](#questions-or-suggestions)
- [Last Words](#last-words)
---
So you want to help? That's great!
@ -12,72 +22,141 @@ So you want to help? That's great!
Here are a few things to get you started on the right path.
**The Docs Structure is dictated by [.vitepress/config.ts](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/docs/.vitepress/config.ts)**.
## Technical Requirements and Setup
**Note: Commits and Pull Requests should be directed to the develop branch.**
### Technical Requirements
## Branching
These are the tools we use for working with the code and documentation.
Mermaid uses a [Git Flow](https://guides.github.com/introduction/flow/)–inspired approach to branching. So development is done in the `develop` branch.
- [volta](https://volta.sh/) to manage node versions.
- [Node.js](https://nodejs.org/en/). `volta install node`
- [pnpm](https://pnpm.io/) package manager. `volta install pnpm`
- [npx](https://docs.npmjs.com/cli/v8/commands/npx) the packaged executor in npm. This is needed [to install pnpm.](#2-install-pnpm)
Once development is done we branch a `release` branch from `develop` for testing.
Follow [the setup steps below](#setup) to install them and verify they are working
Once the release happens we merge the `release` branch with `master` and kill the `release` branch.
### Setup
This means that **you should branch off your pull request from develop** and direct all Pull Requests to it.
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 sucessfully without any errors or failures. (You might see _lint_ or _formatting_ warnings; those are ok during this step.)
## Contributing Code
We make all changes via Pull Requests. As we have many Pull Requests from developers new to mermaid, we have put in place a process, wherein _knsv, Knut Sveidqvist_ is the primary reviewer of changes and merging pull requests. The process is as follows:
The basic steps for contributing code are:
- Large changes reviewed by knsv or other developer asked to review by knsv
- Smaller, low-risk changes like dependencies, documentation, etc. can be merged by active collaborators
- Documentation (we encourage updates to the `/packages/mermaid/src/docs` folder; you can submit them via direct commits)
```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]
```
When you commit code, create a branch with the following naming convention:
```mermaid
graph LR
git[1. Checkout a git branch] --> codeTest[2. write tests and code] --> doc[3. update documentation] --> submit[4.submit a PR]
```
Start with the type, such as **feature** or **bug**, followed by the issue number for reference, and a text that describes the issue.
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._
**One example:**
### 1. Checkout a git branch
`feature/945_state_diagrams`
Mermaid uses a [Git Flow](https://guides.github.com/introduction/flow/)–inspired approach to branching.
**Another example:**
Development is done in the `develop` branch.
`bug/123_nasty_bug_branch`
Once development is done we branch a `release` branch from `develop` for testing.
## Contributing to Documentation
Once the release happens we merge the `release` branch with `master` and delete the `release` branch. The live product and on-line documentation are what is in the `master` branch.
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?
**All new work should be based on the `develop` branch.**
The docs are located in the `src/docs` folder and are written in Markdown. Just pick the right section and start typing. If you want to propose changes to the structure of the documentation, such as adding a new section or a new file you do that via **[.vitepress/config.ts](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/docs/.vitepress/config.ts)**.
**When you are ready to do work, always, ALWAYS:**
> **All the documents displayed in the GitHub.io page are listed in [.vitepress/config.ts](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/docs/.vitepress/config.ts)**.
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.
The contents of <https://mermaid-js.github.io/mermaid/> are based on the docs from the `master` branch. Updates committed to the `master` branch are reflected in the [Mermaid Docs](https://mermaid-js.github.io/mermaid/) once released.
We use the follow naming convention for branches:
## How to Contribute to Documentation
```text
[feature | bug | chore | docs]/[issue number]_[short description using dashes ('-') or underscores ('_') instead of spaces]
```
We are a little less strict here, it is OK to commit directly in the `develop` branch if you are a collaborator.
- 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)
The documentation is located in the `src/docs` directory and organized according to relevant subfolder.
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 dscription. This will help use keep release notes organized: it will help us keep changes for a diagram type together.
The `docs` folder will be automatically generated when committing to `src/docs` and should not be edited manually.
**Ex: A new feature described in issue 2945 that adds a new arrow type called 'florbs' to state diagrams**
We encourage contributions to the documentation at [mermaid-js/mermaid/src/docs](https://github.com/mermaid-js/mermaid/tree/develop/packages/mermaid/src/docs). We publish documentation using GitHub Pages with [Docsify](https://www.youtube.com/watch?v=TV88lp7egMw&t=3s)
`feature/2945_state-diagram-new-arrow-florbs`
### Add Unit Tests for Parsing
**Ex: A bug described in issue 1123 that causes random ugly red text in multiple diagram types**
`bug/1123_fix_random_ugly_red_text`
This is important so that, if someone that does not know about this great feature suggests a change to the grammar, they get notified early on when that change breaks the parser. Another important aspect is that, without proper parsing, tests refactoring is pretty much impossible.
### 2. Write Tests
### Add E2E 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).
This tests 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!
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 for Parsing
If you are adding or changing the text that describes a diagram (the _grammar_), you will need to add (or change) tests for the _parser._
#### 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 run dev` to start the dev server
2. Start **Cypress** by running `pnpm exec cypress open` in the **mermaid** folder.
1. Run `pnpm run dev` to start the dev server (or use the `pnpm dev` script)
2. Start **Cypress** by running `pnpm exec cypress open` in the **mermaid** folder (or use the `pnpm cypress:open` script).
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.
@ -107,17 +186,87 @@ it('should render forks and joins', () => {
});
```
### Any Questions or Suggestions?
\[TODO - running the tests against what is expected in development. ]
After logging in at [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).
\[TODO - how to generate new screenshots]
....
### How to Contribute a Suggestion
### 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!
We know it can sometimes be hard to code _and_ write user documentation.
\[TODO - how to submit documentation changes -- see [Contributing Documentation](#contributing-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!)
### 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 the primary reviewer of changes and merging pull requests. The process is as follows:
- Large changes are reviewed by knsv or other developer asked to review by knsv
- Smaller, low-risk changes like dependencies, documentation, etc. can be reviewed and merged by active collaborators
**Reminder: Pull Requests should be submitted to the develop branch.**
## Contributing Documentation
\[TODO: This section is still a WIP. It still needs 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 `src/docs` folder and are written in Markdown. Just pick the right section and start typing.
If you want to propose changes to the structure of the documentation, such as adding a new section or a new file you do that via the **[sidebar](https://github.com/mermaid-js/mermaid/edit/develop/src/docs/_sidebar.md)**.
> **All the documents displayed in the GitHub.io page are listed in [sidebar.md](https://github.com/mermaid-js/mermaid/edit/develop/src/docs/_sidebar.md)**.
The contents of <https://mermaid-js.github.io/mermaid/> are based on the docs from the `master` branch.
Updates committed to the `master` branch are reflected in the [Mermaid Docs](https://mermaid-js.github.io/mermaid/) once released.
### 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 `src/docs` directory and organized according to relevant subfolder.
The contents of <https://mermaid-js.github.io/mermaid/> are based on the docs from the `master` branch. Updates committed to the `master` branch are reflected in the [Mermaid Docs](https://mermaid-js.github.io/mermaid/) once released.
**The Docs Structure is dictated by [sidebar.md](https://github.com/mermaid-js/mermaid/edit/develop/src/docs/_sidebar.md)**
The `docs` folder will be automatically generated when committing to `src/docs` and should not be edited manually.
We encourage contributions to the documentation at [mermaid-js/mermaid/src/docs](https://github.com/mermaid-js/mermaid/tree/develop/src/docs). We publish documentation using GitHub Pages with [Docsify](https://www.youtube.com/watch?v=TV88lp7egMw&t=3s)
- Documentation (we encourage updates to the `src/docs` folder; you can submit them via direct commits)
The source files for documentation are in `/packages/mermaid/docs` and are written in markdown.
**_DO NOT CHANGE FILES IN `/docs`_**
### The official documentation site
**[The mermaid documentation site](https://mermaid-js.github.io/mermaid/) is powered by [Docsify](https://docsify.js.org), a simple documentation site generator.**
\[TODO - how to preview the documents on a local machine? how to run VitePress?]
If you want to preview the whole documentation site on your machine, you need to install `docsify-cli`:
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:
1. Find the Markdown file (.md) to edit in the [packages/mermaid/src/docs](https://github.com/mermaid-js/mermaid/tree/develop/packages/mermaid/src/docs) directory in the `develop` branch.
1. Find the Markdown file (.md) to edit in the [mermaid-js/mermaid/src/docs](https://github.com/mermaid-js/mermaid/tree/develop/src/docs) directory in the `develop` branch.
2. Create a fork of the develop branch.
3. Make changes or add new documentation.
4. Commit changes to your fork and push it to GitHub.
@ -126,12 +275,31 @@ To edit Docs on your computer:
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).
2. Navigate to [mermaid-js/mermaid/src/docs](https://github.com/mermaid-js/mermaid/tree/develop/src/docs).
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. Create a Pull Request of your newly forked branch by clicking the green **Create Pull Request** button.
## Questions or Suggestions?
#### First search to see if someone has already asked (and hopefully been answered) or suggested the same thing.
- search in the Discussions
- search in the open 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. \[TODO: describe +1, upvote]
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.

9
packages/mermaid/src/docs/community/newDiagram.md
View File

@ -56,9 +56,9 @@ Place the renderer in the diagram folder.
### Step 3: Detection of the new diagram type
The second thing to do is to add the capability to detect the new new diagram to type to the detectType in utils.js. The detection should return a key for the new diagram type.
[This key will be used to as the aria roledescription](#aria-roledescription), so it should be a word that clearly describes the diagram type.
[This key will be used to as the aria roledescription](#aria-roledescription), so it should be a word that clearly describes the diagram type.
For example, if your new diagram use a UML deployment diagram, a good key would be "UMLDeploymentDiagram" because assistive technologies such as a screen reader
would voice that as "U-M-L Deployment diagram." Another good key would be "deploymentDiagram" because that would be voiced as "Deployment Diagram." A bad key would be "deployment" because that would not sufficiently describe the diagram.
would voice that as "U-M-L Deployment diagram." Another good key would be "deploymentDiagram" because that would be voiced as "Deployment Diagram." A bad key would be "deployment" because that would not sufficiently describe the diagram.
Note that the diagram type key does not have to be the same as the diagram keyword chosen for the [grammar](#grammar), but it is helpful if they are the same.
@ -169,11 +169,11 @@ It is probably a good idea to keep the handling similar to this in your new diag
## Accessibility
Mermaid automatically adds the following accessibility information for the diagram SVG HTML element:
- aria-roledescription
- aria-roledescription
- accessible title
- accessible description
### aria-roledescription
The aria-roledescription is automatically set to [the diagram type](#step-3--detection-of-the-new-diagram-type) and inserted into the SVG element.
@ -224,7 +224,6 @@ import {
The accessibility title and description are inserted into the SVG element in the `render` function in mermaidAPI.
## Theming
Mermaid supports themes and has an integrated theming engine. You can read more about how the themes can be used [in the docs](../config/theming.md).

67
packages/mermaid/src/docs/config/accessibility.md
View File

@ -7,15 +7,22 @@ Now with Mermaid library in much wider use, we have started to work towards more
Adding accessibility means that the rich information communicated by visual diagrams can be made available to those using assistive technologies (and of course to search engines).
[Read more about Accessible Rich Internet Applications and the W3 standards.](https://www.w3.org/WAI/standards-guidelines/aria/)
Mermaid will automatically insert the [aria-roledescription](#aria-roledescription) and, if provided in the diagram text by the diagram author, the [accessible title and description.](#accessible-title-and-description)
Mermaid will automatically insert the [aria-roledescription](#aria-roledescription) and, if provided in the diagram text by the diagram author, the [accessible title and description.](#accessible-title-and-description)
### aria-roledescription
The [aria-roledescription](https://www.w3.org/TR/wai-aria-1.1/#aria-roledescription) for the SVG HTML element is set to the diagram type key. (Note this may be slightly different than the keyword used for the diagram in the diagram text.)
The [aria-roledescription](https://www.w3.org/TR/wai-aria-1.1/#aria-roledescription) for the SVG HTML element is set to the diagram type key. (Note this may be slightly different than the keyword used for the diagram in the diagram text.)
For example: The diagram type key for a state diagram is "stateDiagram". Here (a part of) the HTML of the SVG tag that shows the automatically inserted aria-roledscription set to "stateDiagram". _(Note that some of the SVG attributes and the SVG contents are omitted for clarity.):_
```html
<svg aria-roledescription="stateDiagram" class="statediagram" xmlns="http://www.w3.org/2000/svg" width="100%" id="mermaid-1668720491568">
<svg
aria-roledescription="stateDiagram"
class="statediagram"
xmlns="http://www.w3.org/2000/svg"
width="100%"
id="mermaid-1668720491568"
></svg>
```
### Accessible Title and Description
@ -32,23 +39,29 @@ and the accessible description element (text = "This is an accessible descriptio
_(Note that some of the SVG attributes and the SVG contents are omitted for clarity.)_
```html
<svg aria-labelledby="chart-title-mermaid-1668725057758" aria-describedby="chart-desc-mermaid-1668725057758" xmlns="http://www.w3.org/2000/svg" width="100%" id="mermaid-1668725057758">
<svg
aria-labelledby="chart-title-mermaid-1668725057758"
aria-describedby="chart-desc-mermaid-1668725057758"
xmlns="http://www.w3.org/2000/svg"
width="100%"
id="mermaid-1668725057758"
>
<title id="chart-title-mermaid-1668725057758">This is the accessible title</title>
<desc id="chart-desc-mermaid-1668725057758">This is an accessible description</desc>
</svg>
```
Details for the syntax follow.
#### accessible title
The **accessible title** is specified with the **accTitle** _keyword_, followed by a colon (`:`), and the string value for the title.
The string value ends at the end of the line. (It can only be a single line.)
Ex: `accTitle: This is a single line title`
Ex: `accTitle: This is a single line title`
See [the accTitle and accDescr usage examples](#acctitle-and-accdescr-usage-examples) for how this can be used in a diagram and the resulting HTML generated.
#### accessible description
An accessible description can be 1 line long (a single line) or many lines long.
@ -60,6 +73,7 @@ Ex: `accDescr: This is a single line description.`
A **multiple line accessible description** _does not have a colon (`:`) after the accDescr keyword_ and is surrounded by curly brackets (`{}`).
Ex:
```
accDescr { The official Bob's Burgers corporate processes that are used
for making very, very big decisions.
@ -68,7 +82,6 @@ accDescr { The official Bob's Burgers corporate processes that are used
See [the accTitle and accDescr usage examples](#acctitle-and-accdescr-usage-examples) for how this can be used in a diagram and the resulting HTML generated.
#### accTitle and accDescr Usage Examples
- Flowchart with the accessible title "Big Decisions" and the single-line accessible description "Bob's Burgers process for making big decisions"
@ -82,14 +95,22 @@ See [the accTitle and accDescr usage examples](#acctitle-and-accdescr-usage-exam
```
Here is the HTML generated for the SVG element: _(Note that some of the SVG attributes and the SVG contents are omitted for clarity.):_
```html
<svg aria-labelledby="chart-title-mermaid_382ee221" aria-describedby="chart-desc-mermaid_382ee221" aria-roledescription="flowchart-v2" xmlns="http://www.w3.org/2000/svg" width="100%" id="mermaid_382ee221">
<svg
aria-labelledby="chart-title-mermaid_382ee221"
aria-describedby="chart-desc-mermaid_382ee221"
aria-roledescription="flowchart-v2"
xmlns="http://www.w3.org/2000/svg"
width="100%"
id="mermaid_382ee221"
>
<title id="chart-title-mermaid_382ee221">Big decisions</title>
<desc id="chart-desc-mermaid_382ee221">Bob's Burgers process for making big decisions</desc>
</svg>
```
* Flowchart with the accessible title "Bob's Burger's Making Big Decisions" and the multiple line accessible description "The official Bob's Burgers corporate processes that are used
- Flowchart with the accessible title "Bob's Burger's Making Big Decisions" and the multiple line accessible description "The official Bob's Burgers corporate processes that are used
for making very, very big decisions.
This is actually a very simple flow: identify the big decision and then make the big decision."
@ -106,16 +127,25 @@ Here is the HTML generated for the SVG element: _(Note that some of the SVG attr
```
Here is the HTML generated for the SVG element: _(Note that some of the SVG attributes and the SVG contents are omitted for clarity.):_
```html
<svg aria-labelledby="chart-title-mermaid_382ee221" aria-describedby="chart-desc-mermaid_382ee221" aria-roledescription="flowchart-v2" xmlns="http://www.w3.org/2000/svg" width="100%" id="mermaid_382ee221">
<svg
aria-labelledby="chart-title-mermaid_382ee221"
aria-describedby="chart-desc-mermaid_382ee221"
aria-roledescription="flowchart-v2"
xmlns="http://www.w3.org/2000/svg"
width="100%"
id="mermaid_382ee221"
>
<title id="chart-title-mermaid_382ee221">Big decisions</title>
<desc id="chart-desc-mermaid_382ee221">The official Bob's Burgers corporate processes that are used
for making very, very big decisions.
This is actually a very simple flow: identify the big decision and then make the big decision.</desc>
<desc id="chart-desc-mermaid_382ee221">
The official Bob's Burgers corporate processes that are used for making very, very big
decisions. This is actually a very simple flow: identify the big decision and then make the big
decision.
</desc>
</svg>
```
#### Sample Code Snippets for other diagram types
##### Class Diagram
@ -239,7 +269,6 @@ Here is the HTML generated for the SVG element: _(Note that some of the SVG attr
```
##### User Journey Diagram
```mermaid-example