Split development documentation in several separate pages, fixes for the sidebar menu
United similar sections at the intro page Fix spelling Update docs
This commit is contained in:
Nikolay Rozhkov
parent
b85c011cd1
commit
341130856f
|
|
@ -60,7 +60,7 @@ Use Mermaid with your favorite applications, check out the list of [Integrations
|
|||
|
||||
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).
|
||||
|
||||
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/n00b-gettingStarted.md), [Usage](./docs/config/usage.md) and [Tutorials](./docs/config/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.
|
||||
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ Mermaid 通过允许用户创建便于修改的图表来解决这一难题，它
|
|||
Mermaid 甚至能让非程序员也能通过 [Mermaid Live Editor](https://mermaid.live/) 轻松创建详细的图表。<br/>
|
||||
你可以访问 [教程](./docs/config/Tutorials.md) 来查看 Live Editor 的视频教程，也可以查看 [Mermaid 的集成和使用](./docs/ecosystem/integrations.md) 这个清单来检查你的文档工具是否已经集成了 Mermaid 支持。
|
||||
|
||||
如果想要查看关于 Mermaid 更详细的介绍及基础使用方式，可以查看 [入门指引](./docs/community/n00b-overview.md), [用法](./docs/config/usage.md) 和 [教程](./docs/config/Tutorials.md).
|
||||
如果想要查看关于 Mermaid 更详细的介绍及基础使用方式，可以查看 [入门指引](./docs/intro/n00b-gettingStarted.md), [用法](./docs/config/usage.md) 和 [教程](./docs/config/Tutorials.md).
|
||||
|
||||
<!-- </Main description> -->
|
||||
|
||||
|
|
|
|||
|
|
@ -91,6 +91,7 @@
|
|||
"nextra",
|
||||
"nikolay",
|
||||
"nirname",
|
||||
"npmjs",
|
||||
"orlandoni",
|
||||
"pathe",
|
||||
"pbrolin",
|
||||
|
|
|
|||
|
|
@ -0,0 +1,176 @@
|
|||
> **Warning**
|
||||
>
|
||||
> ## THIS IS AN AUTOGENERATED FILE. DO NOT EDIT.
|
||||
>
|
||||
> ## Please edit the corresponding file in [/packages/mermaid/src/docs/community/code.md](../../packages/mermaid/src/docs/community/code.md).
|
||||
|
||||
# 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:
|
||||
|
||||
```txt
|
||||
[feature | bug | chore | docs]/[issue number]_[short description using dashes ('-') or underscores ('_') instead of spaces]
|
||||
```
|
||||
|
||||
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, 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.**
|
||||
|
|
@ -6,15 +6,9 @@
|
|||
|
||||
# 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)
|
||||
|
||||
---
|
||||
> The following documentation describes how to work with Mermaid in your host environment.
|
||||
> There's also a [Docker installation guide](../community/docker-development.md)
|
||||
> if you prefer to work in a Docker environment.
|
||||
|
||||
So you want to help? That's great!
|
||||
|
||||
|
|
@ -22,47 +16,68 @@ So you want to help? That's great!
|
|||
|
||||
Here are a few things to get you started on the right path.
|
||||
|
||||
## Technical Requirements and Setup
|
||||
## Get the Source Code
|
||||
|
||||
### Technical Requirements
|
||||
In GitHub, you first **fork** a repository when you are going to make changes and submit pull requests.
|
||||
|
||||
These are the tools we use for working with the code and documentation.
|
||||
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.
|
||||
|
||||
[Fork mermaid](https://github.com/mermaid-js/mermaid/fork) to start contributing to the main project and its documentaion, or [search for other repositories](https://github.com/orgs/mermaid-js/repositories).
|
||||
|
||||
[Here is a GitHub document that gives an overview of the process.](https://docs.github.com/en/get-started/quickstart/fork-a-repo)
|
||||
|
||||
## Technical Requirements
|
||||
|
||||
> The following documentation describes how to work with Mermaid in your host environment.
|
||||
> There's also a [Docker installation guide](../community/docker-development.md)
|
||||
> if you prefer to work in a Docker environment.
|
||||
|
||||
These are the tools we use for working with the code and documentation:
|
||||
|
||||
- [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)
|
||||
- [npx](https://docs.npmjs.com/cli/v8/commands/npx) the packaged executor in npm. This is needed [to install pnpm.](#install-packages)
|
||||
|
||||
Follow [the setup steps below](#setup) to install them and verify they are working
|
||||
Follow the setup steps below to install them and start the development.
|
||||
|
||||
### Setup
|
||||
## Setup and Launch
|
||||
|
||||
Follow these steps to set up the environment you need to work on code and/or documentation.
|
||||
### Switch to project
|
||||
|
||||
#### 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:
|
||||
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
|
||||
# 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
|
||||
### Install packages
|
||||
|
||||
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:
|
||||
Run `npx pnpm install`. You will need `npx` for this because volta doesn't support it yet.
|
||||
|
||||
```bash
|
||||
npx pnpm install # npx is required for first install
|
||||
```
|
||||
|
||||
### Launch
|
||||
|
||||
```bash
|
||||
npx pnpm run dev
|
||||
```
|
||||
|
||||
Now you are ready to make your changes! Edit whichever files in `src` as required.
|
||||
|
||||
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!)
|
||||
|
||||
## Verify Everything is Working
|
||||
|
||||
You can run the `test` script to verify that pnpm is working _and_ that the repository has been cloned correctly:
|
||||
|
||||
```bash
|
||||
pnpm test
|
||||
|
|
@ -70,321 +85,7 @@ 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.
|
||||
|
||||
```mermaid-example
|
||||
flowchart LR
|
||||
classDef default fill:#fff,color:black,stroke:black
|
||||
|
||||
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"]
|
||||
|
||||
```
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
classDef default fill:#fff,color:black,stroke:black
|
||||
|
||||
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/<Your Username>/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.
|
||||
|
||||
### Documentation organization: Sidebar 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.**
|
||||
|
||||
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
|
||||
All tests should run successfully without any errors or failures. (You might see _lint_ or _formatting_ warnings; those are ok during this step.)
|
||||
|
||||
## Last Words
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,109 @@
|
|||
> **Warning**
|
||||
>
|
||||
> ## THIS IS AN AUTOGENERATED FILE. DO NOT EDIT.
|
||||
>
|
||||
> ## Please edit the corresponding file in [/packages/mermaid/src/docs/community/docker-development.md](../../packages/mermaid/src/docs/community/docker-development.md).
|
||||
|
||||
# Contributing to Mermaid via Docker
|
||||
|
||||
> The following documentation describes how to work with Mermaid in a Docker environment.
|
||||
> There's also a [host installation guide](../community/development.md)
|
||||
> if you prefer to work without a Docker environment.
|
||||
|
||||
So you want to help? That's great!
|
||||
|
||||
|
||||
|
||||
Here are a few things to get you started on the right path.
|
||||
|
||||
## Get the Source Code
|
||||
|
||||
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.
|
||||
|
||||
[Fork mermaid](https://github.com/mermaid-js/mermaid/fork) to start contributing to the main project and its documentaion, or [search for other repositories](https://github.com/orgs/mermaid-js/repositories).
|
||||
|
||||
[Here is a GitHub document that gives an overview of the process.](https://docs.github.com/en/get-started/quickstart/fork-a-repo)
|
||||
|
||||
## Technical Requirements
|
||||
|
||||
> The following documentation describes how to work with Mermaid in a Docker environment.
|
||||
> There's also a [host installation guide](../community/development.md)
|
||||
> if you prefer to work without a Docker environment.
|
||||
|
||||
[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 X11 server installed.
|
||||
Maybe you already have it installed, so check it first:
|
||||
|
||||
```bash
|
||||
echo $DISPLAY
|
||||
```
|
||||
|
||||
If variable `$DISPLAY` is not empty, then it must be working. Otherwise install it.
|
||||
|
||||
## Setup and Launch
|
||||
|
||||
### Switch to project
|
||||
|
||||
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
|
||||
```
|
||||
|
||||
### Make `./run` executable
|
||||
|
||||
For development using Docker there is a self-documented `run` bash script, which provides convenient aliases for `docker compose` commands.
|
||||
|
||||
Ensure `./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.
|
||||
|
||||
### Install packages
|
||||
|
||||
```bash
|
||||
./run pnpm install # Install packages
|
||||
```
|
||||
|
||||
### Launch
|
||||
|
||||
```bash
|
||||
./run dev
|
||||
```
|
||||
|
||||
Now you are ready to make your changes! Edit whichever files in `src` as required.
|
||||
|
||||
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!)
|
||||
|
||||
## Verify Everything is Working
|
||||
|
||||
```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. (You might see _lint_ or _formatting_ warnings; those are ok during this step.)
|
||||
|
||||
## 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)
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,106 @@
|
|||
> **Warning**
|
||||
>
|
||||
> ## THIS IS AN AUTOGENERATED FILE. DO NOT EDIT.
|
||||
>
|
||||
> ## Please edit the corresponding file in [/packages/mermaid/src/docs/community/documentation.md](../../packages/mermaid/src/docs/community/documentation.md).
|
||||
|
||||
# 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.
|
||||
|
||||
```mermaid-example
|
||||
flowchart LR
|
||||
classDef default fill:#fff,color:black,stroke:black
|
||||
|
||||
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"]
|
||||
|
||||
```
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
classDef default fill:#fff,color:black,stroke:black
|
||||
|
||||
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/<Your Username>/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.
|
||||
|
||||
## Documentation organization: Sidebar 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.**
|
||||
|
||||
The sidebar navigation is defined in [the vitepress configuration file config.ts](../.vitepress/config.ts).
|
||||
|
|
@ -1,74 +0,0 @@
|
|||
> **Warning**
|
||||
>
|
||||
> ## THIS IS AN AUTOGENERATED FILE. DO NOT EDIT.
|
||||
>
|
||||
> ## 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
|
||||
<pre class="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.
|
||||
|
|
@ -0,0 +1,28 @@
|
|||
> **Warning**
|
||||
>
|
||||
> ## THIS IS AN AUTOGENERATED FILE. DO NOT EDIT.
|
||||
>
|
||||
> ## Please edit the corresponding file in [/packages/mermaid/src/docs/community/questionsAndSuggestions.md](../../packages/mermaid/src/docs/community/questionsAndSuggestions.md).
|
||||
|
||||
# Questions or Suggestions?
|
||||
|
||||
**_\[TODO: This section is still a WIP. It still needs MAJOR revision.]_**
|
||||
|
||||
## 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
|
||||
|
|
@ -322,6 +322,7 @@ To Deploy Mermaid:
|
|||
- [Mermaid CLI](https://github.com/mermaid-js/mermaid-cli)
|
||||
- [Mermaid Webpack Demo](https://github.com/mermaidjs/mermaid-webpack-demo)
|
||||
- [Mermaid Parcel Demo](https://github.com/mermaidjs/mermaid-parcel-demo)
|
||||
- [HTTP Server](https://github.com/TomWright/mermaid-server)
|
||||
|
||||
## Request for Assistance
|
||||
|
||||
|
|
@ -338,7 +339,17 @@ Together we could continue the work with things like:
|
|||
|
||||
Don't hesitate to contact me if you want to get involved!
|
||||
|
||||
## For contributors
|
||||
## Contributors
|
||||
|
||||
<div class='badges'>
|
||||
|
||||
[](https://github.com/mermaid-js/mermaid/issues?q=is%3Aissue+is%3Aopen+label%3A%22Good+first+issue%21%22) [](https://github.com/mermaid-js/mermaid/graphs/contributors) [](https://github.com/mermaid-js/mermaid/graphs/contributors)
|
||||
|
||||
</div>
|
||||
|
||||
Mermaid is a growing community and is always accepting new contributors. There's a lot of different ways to help out and we're always looking for extra hands! Look at [this issue](https://github.com/mermaid-js/mermaid/issues/866) if you want to know where to start helping out.
|
||||
|
||||
Detailed information about how to contribute can be found in the [contribution guideline](/community/development).
|
||||
|
||||
### Requirements
|
||||
|
||||
|
|
@ -346,7 +357,7 @@ Don't hesitate to contact me if you want to get involved!
|
|||
- [Node.js](https://nodejs.org/en/). `volta install node`
|
||||
- [pnpm](https://pnpm.io/) package manager. `volta install pnpm`
|
||||
|
||||
## Development Installation
|
||||
### Development Installation
|
||||
|
||||
```bash
|
||||
git clone git@github.com:mermaid-js/mermaid.git
|
||||
|
|
@ -383,25 +394,7 @@ Update version number in `package.json`.
|
|||
npm publish
|
||||
```
|
||||
|
||||
The above command generates files into the `dist` folder and publishes them to \<npmjs.org>.
|
||||
|
||||
## Related projects
|
||||
|
||||
- [Command Line Interface](https://github.com/mermaid-js/mermaid-cli)
|
||||
- [Live Editor](https://github.com/mermaid-js/mermaid-live-editor)
|
||||
- [HTTP Server](https://github.com/TomWright/mermaid-server)
|
||||
|
||||
## Contributors
|
||||
|
||||
<div class='badges'>
|
||||
|
||||
[](https://github.com/mermaid-js/mermaid/issues?q=is%3Aissue+is%3Aopen+label%3A%22Good+first+issue%21%22) [](https://github.com/mermaid-js/mermaid/graphs/contributors) [](https://github.com/mermaid-js/mermaid/graphs/contributors)
|
||||
|
||||
</div>
|
||||
|
||||
Mermaid is a growing community and is always accepting new contributors. There's a lot of different ways to help out and we're always looking for extra hands! Look at [this issue](https://github.com/mermaid-js/mermaid/issues/866) if you want to know where to start helping out.
|
||||
|
||||
Detailed information about how to contribute can be found in the [contribution guide](https://github.com/mermaid-js/mermaid/blob/develop/CONTRIBUTING.md)
|
||||
The above command generates files into the `dist` folder and publishes them to [npmjs.org](npmjs.org).
|
||||
|
||||
## Security and safe diagrams
|
||||
|
||||
|
|
|
|||
|
|
@ -56,11 +56,11 @@ One should **beware the use of some words or symbols** that can break diagrams.
|
|||
| 'end' | The word "End" can cause Flowcharts and Sequence diagrams to break | Wrap them in quotation marks to prevent breakage. |
|
||||
| [Nodes inside Nodes](../syntax/flowchart.md?id=special-characters-that-break-syntax) | Mermaid gets confused with nested shapes | wrap them in quotation marks to prevent breaking |
|
||||
|
||||
### Mermaid Live Editor
|
||||
## Mermaid Live Editor
|
||||
|
||||
Now, that you've seen what you should not add to your diagrams, you can play around with them in the [Mermaid Live Editor](https://mermaid.live).
|
||||
|
||||
# Configuration
|
||||
## Configuration
|
||||
|
||||
Configuration is the third part of Mermaid, after deployment and syntax. It deals with the different ways that Mermaid can be customized across different deployments.
|
||||
|
||||
|
|
|
|||
|
|
@ -72,6 +72,11 @@ function nav() {
|
|||
activeMatch: '/config/',
|
||||
},
|
||||
{ text: 'Integrations', link: '/ecosystem/integrations', activeMatch: '/ecosystem/' },
|
||||
{
|
||||
text: 'Contributing',
|
||||
link: '/community/development.html',
|
||||
activeMatch: '/community/',
|
||||
},
|
||||
{
|
||||
text: 'Latest News',
|
||||
link: '/news/announcements',
|
||||
|
|
@ -104,11 +109,8 @@ function sidebarAll() {
|
|||
collapsed: false,
|
||||
items: [
|
||||
{ text: 'About Mermaid', link: '/intro/' },
|
||||
{ text: 'Deployment', link: '/intro/n00b-gettingStarted' },
|
||||
{
|
||||
text: 'Syntax and Configuration',
|
||||
link: '/intro/n00b-syntaxReference',
|
||||
},
|
||||
{ text: 'Getting Started', link: '/intro/n00b-gettingStarted' },
|
||||
{ text: 'Syntax and Configuration', link: '/intro/n00b-syntaxReference' },
|
||||
],
|
||||
},
|
||||
...sidebarSyntax(),
|
||||
|
|
@ -191,8 +193,10 @@ function sidebarCommunity() {
|
|||
text: '🙌 Contributions and Community',
|
||||
collapsed: false,
|
||||
items: [
|
||||
{ text: 'Overview for Beginners', link: '/community/n00b-overview' },
|
||||
...sidebarCommunityDevelopContribute(),
|
||||
{ text: 'Contributing to Mermaid', link: '/community/development' },
|
||||
{ text: 'Contributing Code', link: '/community/code' },
|
||||
{ text: 'Contributing Documentation', link: '/community/documentation' },
|
||||
{ text: 'Questions and Suggestions', link: '/community/questionsAndSuggestions' },
|
||||
{ text: 'Adding Diagrams', link: '/community/newDiagram' },
|
||||
{ text: 'Security', link: '/community/security' },
|
||||
],
|
||||
|
|
@ -200,40 +204,6 @@ function sidebarCommunity() {
|
|||
];
|
||||
}
|
||||
|
||||
// Development and Contributing
|
||||
function sidebarCommunityDevelopContribute() {
|
||||
const page_path = '/community/development';
|
||||
return [
|
||||
{
|
||||
text: 'Contributing to Mermaid',
|
||||
link: page_path + '#contributing-to-mermaid',
|
||||
collapsed: false,
|
||||
items: [
|
||||
{
|
||||
text: 'Technical Requirements and Setup',
|
||||
link: pathToId(page_path, 'technical-requirements-and-setup'),
|
||||
},
|
||||
{
|
||||
text: 'Contributing Code',
|
||||
link: pathToId(page_path, 'contributing-code'),
|
||||
},
|
||||
{
|
||||
text: 'Contributing Documentation',
|
||||
link: pathToId(page_path, 'contributing-documentation'),
|
||||
},
|
||||
{
|
||||
text: 'Questions or Suggestions?',
|
||||
link: pathToId(page_path, 'questions-or-suggestions'),
|
||||
},
|
||||
{
|
||||
text: 'Last Words',
|
||||
link: pathToId(page_path, 'last-words'),
|
||||
},
|
||||
],
|
||||
},
|
||||
];
|
||||
}
|
||||
|
||||
function sidebarNews() {
|
||||
return [
|
||||
{
|
||||
|
|
|
|||
|
|
@ -50,6 +50,7 @@ const idRedirectMap: Record<string, string> = {
|
|||
'n00b-advanced': 'config/n00b-advanced',
|
||||
'n00b-gettingstarted': 'intro/n00b-gettingStarted',
|
||||
'n00b-overview': 'community/n00b-overview',
|
||||
'community/n00b-overview': 'intro/n00b-gettingStarted',
|
||||
'n00b-syntaxreference': 'intro/n00b-syntaxReference',
|
||||
newdiagram: 'community/newDiagram',
|
||||
pie: 'syntax/pie',
|
||||
|
|
|
|||
|
|
@ -0,0 +1,165 @@
|
|||
# Contributing Code
|
||||
|
||||
The basic steps for contributing code are:
|
||||
|
||||
```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:
|
||||
|
||||
```txt
|
||||
[feature | bug | chore | docs]/[issue number]_[short description using dashes ('-') or underscores ('_') instead of spaces]
|
||||
```
|
||||
|
||||
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, 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.**
|
||||
|
|
@ -1,14 +1,8 @@
|
|||
# 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)
|
||||
|
||||
---
|
||||
> The following documentation describes how to work with Mermaid in your host environment.
|
||||
> There's also a [Docker installation guide](../community/docker-development.md)
|
||||
> if you prefer to work in a Docker environment.
|
||||
|
||||
So you want to help? That's great!
|
||||
|
||||
|
|
@ -16,47 +10,68 @@ So you want to help? That's great!
|
|||
|
||||
Here are a few things to get you started on the right path.
|
||||
|
||||
## Technical Requirements and Setup
|
||||
## Get the Source Code
|
||||
|
||||
### Technical Requirements
|
||||
In GitHub, you first **fork** a repository when you are going to make changes and submit pull requests.
|
||||
|
||||
These are the tools we use for working with the code and documentation.
|
||||
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.
|
||||
|
||||
[Fork mermaid](https://github.com/mermaid-js/mermaid/fork) to start contributing to the main project and its documentaion, or [search for other repositories](https://github.com/orgs/mermaid-js/repositories).
|
||||
|
||||
[Here is a GitHub document that gives an overview of the process.](https://docs.github.com/en/get-started/quickstart/fork-a-repo)
|
||||
|
||||
## Technical Requirements
|
||||
|
||||
> The following documentation describes how to work with Mermaid in your host environment.
|
||||
> There's also a [Docker installation guide](../community/docker-development.md)
|
||||
> if you prefer to work in a Docker environment.
|
||||
|
||||
These are the tools we use for working with the code and documentation:
|
||||
|
||||
- [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)
|
||||
- [npx](https://docs.npmjs.com/cli/v8/commands/npx) the packaged executor in npm. This is needed [to install pnpm.](#install-packages)
|
||||
|
||||
Follow [the setup steps below](#setup) to install them and verify they are working
|
||||
Follow the setup steps below to install them and start the development.
|
||||
|
||||
### Setup
|
||||
## Setup and Launch
|
||||
|
||||
Follow these steps to set up the environment you need to work on code and/or documentation.
|
||||
### Switch to project
|
||||
|
||||
#### 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:
|
||||
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
|
||||
# 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
|
||||
### Install packages
|
||||
|
||||
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:
|
||||
Run `npx pnpm install`. You will need `npx` for this because volta doesn't support it yet.
|
||||
|
||||
```bash
|
||||
npx pnpm install # npx is required for first install
|
||||
```
|
||||
|
||||
### Launch
|
||||
|
||||
```bash
|
||||
npx pnpm run dev
|
||||
```
|
||||
|
||||
Now you are ready to make your changes! Edit whichever files in `src` as required.
|
||||
|
||||
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!)
|
||||
|
||||
## Verify Everything is Working
|
||||
|
||||
You can run the `test` script to verify that pnpm is working _and_ that the repository has been cloned correctly:
|
||||
|
||||
```bash
|
||||
pnpm test
|
||||
|
|
@ -64,309 +79,7 @@ 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
|
||||
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.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
classDef default fill:#fff,color:black,stroke:black
|
||||
|
||||
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/](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/<Your Username>/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.
|
||||
|
||||
### Documentation organization: Sidebar 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.**
|
||||
|
||||
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
|
||||
All tests should run successfully without any errors or failures. (You might see _lint_ or _formatting_ warnings; those are ok during this step.)
|
||||
|
||||
## Last Words
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,104 @@
|
|||
# Contributing to Mermaid via Docker
|
||||
|
||||
> The following documentation describes how to work with Mermaid in a Docker environment.
|
||||
> There's also a [host installation guide](../community/development.md)
|
||||
> if you prefer to work without a Docker environment.
|
||||
|
||||
So you want to help? That's great!
|
||||
|
||||
|
||||
|
||||
Here are a few things to get you started on the right path.
|
||||
|
||||
## Get the Source Code
|
||||
|
||||
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.
|
||||
|
||||
[Fork mermaid](https://github.com/mermaid-js/mermaid/fork) to start contributing to the main project and its documentaion, or [search for other repositories](https://github.com/orgs/mermaid-js/repositories).
|
||||
|
||||
[Here is a GitHub document that gives an overview of the process.](https://docs.github.com/en/get-started/quickstart/fork-a-repo)
|
||||
|
||||
## Technical Requirements
|
||||
|
||||
> The following documentation describes how to work with Mermaid in a Docker environment.
|
||||
> There's also a [host installation guide](../community/development.md)
|
||||
> if you prefer to work without a Docker environment.
|
||||
|
||||
[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 X11 server installed.
|
||||
Maybe you already have it installed, so check it first:
|
||||
|
||||
```bash
|
||||
echo $DISPLAY
|
||||
```
|
||||
|
||||
If variable `$DISPLAY` is not empty, then it must be working. Otherwise install it.
|
||||
|
||||
## Setup and Launch
|
||||
|
||||
### Switch to project
|
||||
|
||||
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
|
||||
```
|
||||
|
||||
### Make `./run` executable
|
||||
|
||||
For development using Docker there is a self-documented `run` bash script, which provides convenient aliases for `docker compose` commands.
|
||||
|
||||
Ensure `./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.
|
||||
```
|
||||
|
||||
### Install packages
|
||||
|
||||
```bash
|
||||
./run pnpm install # Install packages
|
||||
```
|
||||
|
||||
### Launch
|
||||
|
||||
```bash
|
||||
./run dev
|
||||
```
|
||||
|
||||
Now you are ready to make your changes! Edit whichever files in `src` as required.
|
||||
|
||||
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!)
|
||||
|
||||
## Verify Everything is Working
|
||||
|
||||
```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. (You might see _lint_ or _formatting_ warnings; those are ok during this step.)
|
||||
|
||||
## 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)
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,93 @@
|
|||
# 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.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
classDef default fill:#fff,color:black,stroke:black
|
||||
|
||||
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/](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/<Your Username>/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.
|
||||
|
||||
## Documentation organization: Sidebar 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.**
|
||||
|
||||
The sidebar navigation is defined in [the vitepress configuration file config.ts](../.vitepress/config.ts).
|
||||
|
|
@ -1,68 +0,0 @@
|
|||
# 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
|
||||
<pre class="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.
|
||||
|
|
@ -0,0 +1,22 @@
|
|||
# Questions or Suggestions?
|
||||
|
||||
**_[TODO: This section is still a WIP. It still needs MAJOR revision.]_**
|
||||
|
||||
## 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
|
||||
|
|
@ -99,6 +99,7 @@ To Deploy Mermaid:
|
|||
- [Mermaid CLI](https://github.com/mermaid-js/mermaid-cli)
|
||||
- [Mermaid Webpack Demo](https://github.com/mermaidjs/mermaid-webpack-demo)
|
||||
- [Mermaid Parcel Demo](https://github.com/mermaidjs/mermaid-parcel-demo)
|
||||
- [HTTP Server](https://github.com/TomWright/mermaid-server)
|
||||
|
||||
## Request for Assistance
|
||||
|
||||
|
|
@ -115,7 +116,17 @@ Together we could continue the work with things like:
|
|||
|
||||
Don't hesitate to contact me if you want to get involved!
|
||||
|
||||
## For contributors
|
||||
## Contributors
|
||||
|
||||
<div class='badges'>
|
||||
|
||||
[](https://github.com/mermaid-js/mermaid/issues?q=is%3Aissue+is%3Aopen+label%3A%22Good+first+issue%21%22) [](https://github.com/mermaid-js/mermaid/graphs/contributors) [](https://github.com/mermaid-js/mermaid/graphs/contributors)
|
||||
|
||||
</div>
|
||||
|
||||
Mermaid is a growing community and is always accepting new contributors. There's a lot of different ways to help out and we're always looking for extra hands! Look at [this issue](https://github.com/mermaid-js/mermaid/issues/866) if you want to know where to start helping out.
|
||||
|
||||
Detailed information about how to contribute can be found in the [contribution guideline](/community/development).
|
||||
|
||||
### Requirements
|
||||
|
||||
|
|
@ -123,7 +134,7 @@ Don't hesitate to contact me if you want to get involved!
|
|||
- [Node.js](https://nodejs.org/en/). `volta install node`
|
||||
- [pnpm](https://pnpm.io/) package manager. `volta install pnpm`
|
||||
|
||||
## Development Installation
|
||||
### Development Installation
|
||||
|
||||
```bash
|
||||
git clone git@github.com:mermaid-js/mermaid.git
|
||||
|
|
@ -160,25 +171,7 @@ Update version number in `package.json`.
|
|||
npm publish
|
||||
```
|
||||
|
||||
The above command generates files into the `dist` folder and publishes them to <npmjs.org>.
|
||||
|
||||
## Related projects
|
||||
|
||||
- [Command Line Interface](https://github.com/mermaid-js/mermaid-cli)
|
||||
- [Live Editor](https://github.com/mermaid-js/mermaid-live-editor)
|
||||
- [HTTP Server](https://github.com/TomWright/mermaid-server)
|
||||
|
||||
## Contributors
|
||||
|
||||
<div class='badges'>
|
||||
|
||||
[](https://github.com/mermaid-js/mermaid/issues?q=is%3Aissue+is%3Aopen+label%3A%22Good+first+issue%21%22) [](https://github.com/mermaid-js/mermaid/graphs/contributors) [](https://github.com/mermaid-js/mermaid/graphs/contributors)
|
||||
|
||||
</div>
|
||||
|
||||
Mermaid is a growing community and is always accepting new contributors. There's a lot of different ways to help out and we're always looking for extra hands! Look at [this issue](https://github.com/mermaid-js/mermaid/issues/866) if you want to know where to start helping out.
|
||||
|
||||
Detailed information about how to contribute can be found in the [contribution guide](https://github.com/mermaid-js/mermaid/blob/develop/CONTRIBUTING.md)
|
||||
The above command generates files into the `dist` folder and publishes them to [npmjs.org](npmjs.org).
|
||||
|
||||
## Security and safe diagrams
|
||||
|
||||
|
|
|
|||
|
|
@ -38,11 +38,11 @@ One should **beware the use of some words or symbols** that can break diagrams.
|
|||
| 'end' | The word "End" can cause Flowcharts and Sequence diagrams to break | Wrap them in quotation marks to prevent breakage. |
|
||||
| [Nodes inside Nodes](../syntax/flowchart.md?id=special-characters-that-break-syntax) | Mermaid gets confused with nested shapes | wrap them in quotation marks to prevent breaking |
|
||||
|
||||
### Mermaid Live Editor
|
||||
## Mermaid Live Editor
|
||||
|
||||
Now, that you've seen what you should not add to your diagrams, you can play around with them in the [Mermaid Live Editor](https://mermaid.live).
|
||||
|
||||
# Configuration
|
||||
## Configuration
|
||||
|
||||
Configuration is the third part of Mermaid, after deployment and syntax. It deals with the different ways that Mermaid can be customized across different deployments.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue