mirrors
/
mermaid
mirror of https://github.com/mermaid-js/mermaid.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Different fixes

This commit is contained in:
Nikolay Rozhkov 2023-12-19 03:56:16 +03:00
parent 5b58883db8
commit 2705c0de03
7 changed files with 539 additions and 86 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

78
contrib.md Normal file
View File

@ -0,0 +1,78 @@
FIXME: remove before merge, this is previous contributing.md
## Contributing Guide
Please read in detail about how to contribute documentation and code on the [Mermaid documentation site.](https://mermaid-js.github.io/mermaid/#/development)
## Mermaid contribution cheat-sheet
### Requirements
- [volta](https://volta.sh/) to manage node versions.
- [Node.js](https://nodejs.org/en/). `volta install node`
- [pnpm](https://pnpm.io/) package manager. `volta install pnpm`
### Development Installation
If you don't have direct access to push to mermaid repositories, make a fork first. Then clone. Or clone directly from mermaid-js:
```bash
git clone git@github.com:mermaid-js/mermaid.git
cd mermaid
```
Install required packages:
```bash
## npx is required for first install as volta support for pnpm is not added yet.
npx pnpm install
pnpm test # run unit tests
pnpm dev # starts a dev server
```
Open <http://localhost:9000> in your browser after starting the dev server.
You can also duplicate the `example.html` file in `demos/dev`, rename it and add your own mermaid code to it.
That will be served at <http://localhost:9000/dev/your-file-name.html>.
#### 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
```
### Testing
```bash
## Run unit test
pnpm test
## Run unit test in watch mode
pnpm test:watch
## Run E2E test
pnpm e2e
## Debug E2E tests
pnpm dev
pnpm cypress:open # in another terminal
```
### Branch name format:
```text
[feature | bug | chore | docs]/[issue number]_[short description using dashes ('-') or underscores ('_') instead of spaces]
```
eg: `feature/2945_state-diagram-new-arrow-florbs`, `bug/1123_fix_random_ugly_red_text`
### Documentation
Documentation is necessary for all non bugfix/refactoring changes.
Only make changes to files that are in [`/packages/mermaid/src/docs`](packages/mermaid/src/docs)
**_DO NOT CHANGE FILES IN `/docs` MANUALLY_**
The `/docs` folder will be rebuilt and committed as part of a pre-commit hook.
[Join our slack community if you want closer contact!](https://join.slack.com/t/mermaid-talk/shared_invite/enQtNzc4NDIyNzk4OTAyLWVhYjQxOTI2OTg4YmE1ZmJkY2Y4MTU3ODliYmIwOTY3NDJlYjA0YjIyZTdkMDMyZTUwOGI0NjEzYmEwODcwOTE)

4
packages/mermaid/src/docs/.vitepress/config.ts
View File

@ -201,8 +201,8 @@ function sidebarCommunity() {
collapsed: false,
items: [
{ text: 'Contributing to Mermaid', link: '/contributing/intro' },
{ text: 'Contributing guide', link: '/contributing/contributing' },
{ text: 'Initial setup', link: '/contributing/setup' },
{ text: 'Contributing Guide', link: '/contributing/contributing' },
{ text: 'Initial Setup', link: '/contributing/setup' },
{ text: 'Workflow', link: '/contributing/workflow' },
{ text: 'Code', link: '/contributing/code' },
{ text: 'Documentation', link: '/contributing/documentation' },

4
packages/mermaid/src/docs/community/code.md
View File

@ -107,8 +107,8 @@ it('should render forks and joins', () => {
});
```
**_[TODO - running the tests against what is expected in development. ]_**
**_[TODO - how to generate new screenshots]_**
<!-- **_[TODO - running the tests against what is expected in development. ]_** -->
<!-- **_[TODO - how to generate new screenshots]_** -->
## Update Documentation

458
packages/mermaid/src/docs/community/contributing.md
View File

@ -1,78 +1,456 @@
---
# Old Contributing Guide
# Mermaid Contributing Guide
Please read in detail about how to contribute documentation and code on the [Mermaid documentation site.](https://mermaid-js.github.io/mermaid/#/development)
---
## Get the Source Code
# Mermaid contribution cheat-sheet
In GitHub, you first **fork** a repository when you are going to make changes and submit pull requests.
## Requirements
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 documentation, 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).
```bash
git clone git@github.com/your-fork/mermaid
```
Once you have cloned the repository onto your development machine, change into the `mermaid` project folder (the top level directory of the mermaid project repository)
```bash
cd mermaid
```
## Install Requirements
We support **development within Docker** environment along with **host setup**. You may choose it up to your preferences.
#### Host
These are the tools we use for working with the code and documentation:
- [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.](#install-packages)
## Development Installation
#### Docker
If you don't have direct access to push to mermaid repositories, make a fork first. Then clone. Or clone directly from mermaid-js:
[Install Docker](https://docs.docker.com/engine/install/). And that is pretty much all you need.
Optionally, to run GUI (Cypress) within Docker you will also need an X11 server installed.
You might already have it installed, so check this by running:
```bash
git clone git@github.com:mermaid-js/mermaid.git
cd mermaid
echo $DISPLAY
```
Install required packages:
If the `$DISPLAY` variable is not empty, then an X11 server is running. Otherwise you may need to install one.
### Install packages
#### Host
Run `npx pnpm install`. You will need `npx` for this because `volta` doesn't support it yet.
```bash
# npx is required for first install as volta support for pnpm is not added yet.
npx pnpm install
pnpm test # run unit tests
pnpm dev # starts a dev server
npx pnpm install # npx is required for first install
```
Open <http://localhost:9000> in your browser after starting the dev server.
You can also duplicate the `example.html` file in `demos/dev`, rename it and add your own mermaid code to it.
That will be served at <http://localhost:9000/dev/your-file-name.html>.
#### Docker
### Docker
For development using Docker there is a self-documented `run` bash script, which provides convenient aliases for `docker compose` commands.
If you are using docker and docker-compose, you have self-documented `run` bash script, which is a convenient alias for docker-compose commands:
Make sure that `./run` script is executable:
```bash
./run install # npx pnpm install
./run test # pnpm test
chmod +x run
```
## Testing
```tip
To get detailed help simply type `./run` or `./run help`.
It also has short _Development quick start guide_ embedded.
```
```bash
./run pnpm install # Install packages
```
### Verify Everything Works
This step is optional, but it helps to make sure that everything in development branch was OK before you started making any changes.
You can run the `test` script to verify that pnpm is working _and_ that the repository has been cloned correctly:
**Host**
```bash
# Run unit test
pnpm test
# Run unit test in watch mode
```
**Docker**
```bash
./run pnpm test
```
The `test` script and others are in the top-level `package.json` file.
All tests should run successfully without any errors or failures. (You might see _lint_ or _formatting_ warnings; those are ok during this step.)
## Workflow
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.
The basic steps to start contributing code and documentation are:
```mermaid-nocode
flowchart TB
fetch --> branch --> update --> submit --> review --> fetch
fetch[Fetch development branch]
branch[Checkout a new branch]
update[Make changes]
submit[Submit a PR]
review[Review and merge]
```
### Fech latest code
```tip
All new work should be based on the `develop` branch.
```
Make sure you have the most up-to-date version of the `develop` branch.
Check out the `develop` branch, then `fetch` or `pull` to update it:
```bash
git checkout develop
git fetch # or `git pull`
```
### Checkout new branch
Create a new branch for your work:
```bash
git checkout develop # make sure you are on development branch
git checkout -b docs/2910_update-contributing-guidelines
```
We use the following naming convention for branches:
```txt
[feature | bug | chore | docs]/[issue number]_[short-description]
```
You can always check current [configuration of labelling and branch prefixes](https://github.com/mermaid-js/mermaid/blob/develop/.github/pr-labeler.yml)
- The first part is the **type** of change: a `feature`, `bug`, `chore`, `docs`
- followed by a **slash** (`/`),which helps to group like types together in many git tools
- followed by the **issue number**, e.g. `2910`
- followed by an **underscore** (`_`)
- followed by a **short description** with dashes (`-`) or underscores (`_`) instead of spaces
```mermaid-nocode
flowchart LR
feature --> slash
bug --> slash
chore --> slash
docs --> slash
slash --> 2945 --> underscore
slash --> 1123 --> underscore
underscore --> short_description_1
underscore --> short_description_2
underscore["_"]
slash["/"]
short_description_1["state-diagram-new-arrow-florbs"]
short_description_2["fix_random_ugly_red_text"]
```
If your work is specific to a single diagram type, it is a good idea to put the diagram type at the start of the description. This will help us keep release notes organized by a diagram type.
```note
A new feature described in issue 2945 that adds a new arrow type called 'florbs' to state diagrams
`feature/2945_state-diagram-new-arrow-florbs`
```
```tip
A bug described in issue 1123 that causes random ugly red text in multiple diagram types
`bug/1123_fix_random_ugly_red_text`
```
### Make changes
Source code and the documentation are located [`packages/mermaid`]((https://github.com/mermaid-js/mermaid/tree/develop/packages/mermaid) folder.
You may need to update both, depending on your task.
Read our guides on [how to contribute to code](./code.md) and [how to contribute to documentation](./documentation.md).
## Contributing Code
Code it the heart of every software project. We strive to make it better. Who if not us?
### Where is the code located?
The core of Mermaid is located under `packages/mermaid/src`.
### Running Mermaid Locally
**Host**
```bash
npx pnpm run dev
```
**Docker**
```bash
./run dev
```
After starting the dev server open <http://localhost:9000> in your browser.
Now you are ready to make your changes!
### Make Changes
Have a look at <http://localhost:9000>. There is a list of demos that can be used to see and test your changes.
If you need a specific diagram, you can duplicate the `example.html` file in `/demos/dev` and add your own mermaid code to your copy.
That will be served at <http://localhost:9000/dev/your-file-name.html>.
After making code changes, the dev server will rebuild the mermaid library. You will need to reload the browser page yourself to see the changes. (PRs for auto reload are welcome!)
Edit files in `packages/mermaid/src` as required.
### Write Tests
Tests ensure that each function, module, or part of code does what it says it will do. This is critically
important when other changes are made to ensure that existing code is not broken (no regression).
Just as important, the tests act as _specifications:_ they specify what the code does (or should do).
Whenever someone is new to a section of code, they should be able to read the tests to get a thorough understanding of what it does and why.
If you are fixing a bug, you should add tests to ensure that your code has actually fixed the bug, to specify/describe what the code is doing, and to ensure the bug doesn't happen again.
(If there had been a test for the situation, the bug never would have happened in the first place.)
You may need to change existing tests if they were inaccurate.
If you are adding a feature, you will definitely need to add tests. Depending on the size of your feature, you may need to add integration tests.
#### Unit Tests
Unit tests are tests that test a single function or module. They are the easiest to write and the fastest to run.
Unit tests are mandatory 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
# Run E2E test
pnpm e2e
# Debug E2E tests
pnpm dev
pnpm cypress:open # in another terminal
```
## Branch name format:
#### Integration/End-to-End (e2e) tests
```text
[feature | bug | chore | docs]/[issue number]_[short description using dashes ('-') or underscores ('_') instead of spaces]
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 &lt;&lt;fork&gt;&gt;
[*] --> fork_state
fork_state --> State2
fork_state --> State3
state join_state &lt;&lt;join&gt;&gt;
State2 --> join_state
State3 --> join_state
join_state --> State4
State4 --> [*]
`,
{ logLevel: 0 }
);
cy.get('svg');
});
```
eg: `feature/2945_state-diagram-new-arrow-florbs`, `bug/1123_fix_random_ugly_red_text`
<!-- **_[TODO - running the tests against what is expected in development. ]_** -->
<!-- **_[TODO - how to generate new screenshots]_** -->
## Documentation
### Update Documentation
Documentation is necessary for all non bugfix/refactoring changes.
```tip
Our documentation is managed in `packages/mermaid/src/docs`. Details on how to edit is in the [documentation section](documentation)
```
Only make changes to files that are in [`/packages/mermaid/src/docs`](packages/mermaid/src/docs)
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.
**_DO NOT CHANGE FILES IN `/docs` MANUALLY_**
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.
The `/docs` folder will be rebuilt and committed as part of a pre-commit hook.
eg: `# Feature Name (v<MERMAID_RELEASE_VERSION>+)`
[Join our slack community if you want closer contact!](https://join.slack.com/t/mermaid-talk/shared_invite/enQtNzc4NDIyNzk4OTAyLWVhYjQxOTI2OTg4YmE1ZmJkY2Y4MTU3ODliYmIwOTY3NDJlYjA0YjIyZTdkMDMyZTUwOGI0NjEzYmEwODcwOTE)
We know it can sometimes be hard to code _and_ write user documentation.
Create another issue specifically for the documentation.
You will need to help with the PR, but definitely ask for help if you feel stuck.
When it feels hard to write stuff out, explaining it to someone and having that person ask you clarifying questions can often be 80% of the work!
When in doubt, write up and submit what you can. It can be clarified and refined later. (With documentation, something is better than nothing!)
## Contributing Documentation
If it is not in the documentation, it's like it never happened. Wouldn't that be sad? With all the effort that was put into the feature?
### Where is the Documentation Located?
```warning
DO NOT CHANGE FILES IN `/docs`
The `docs` folder will be automatically generated when committing to `packages/mermaid/src/docs` and **should not** be edited manually.
```
It is located in the [`packages/mermaid/src/docs`](https://github.com/mermaid-js/mermaid/tree/develop/packages/mermaid/src/docs) folder. Just pick the right section and start typing.
The contents of [mermaid.js.org](https://mermaid.js.org/) are based on the docs from the `master` branch. Updates committed to the `master` branch are reflected in the [Mermaid Docs](https://mermaid.js.org/) once published.
```mermaid
flowchart LR
classDef default fill:#fff,color:black,stroke:black
source["Edit /packages/mermaid/src/docs"] -- automatic processing--> published["View /docs which will be publised on Official Website"]
```
### Enable Github Actions
```warning
So as to allow automatic compilation of documentation pages you have to enable github actions on your fork first
```
### Running the Documentation Website Locally
**[The mermaid documentation site](https://mermaid.js.org/) is powered by [Vitepress](https://vitepress.vuejs.org/).**
Start development server for the documentation site
**Host**
```bash
pnpm --filter mermaid run docs:dev
```
or
```bash
cd packages/mermaid
pnpm docs:dev
```
**Docker**
```
./run docs:dev
```
Open [http://localhost:3333/](http://localhost:3333/) in your browser.
### Format
The documentation is written in Markdown. To get acquainted with its syntax [see the GitHub Markdown help page](https://help.github.com/en/github/writing-on-github/basic-writing-and-formatting-syntax).
You can use `note`, `tip`, `warning` and `danger` in triple backticks to add a note, tip, warning or danger box.
```danger
Do not use vitepress specific markdown syntax `::: warning` as it will not be processed correctly.
```
````markdown
```note
This is a note
```
```tip
This is a tip
```
```warning
This is a warning
```
```danger
This is a danger alert
```
````
### 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).
## Submit your pull request
````note
Do not forget to push your changes
```bash
git push -u origin docs/2910_update-contributing-guidelines
```
````
We make all changes via Pull Requests (PRs). Open a new one.
Right now we are not following any strict rules about naming PRs. Give it a representative title and short description. There is also a [pull_request_template](https://github.com/mermaid-js/mermaid/blob/develop/.github/pull_request_template.md) which will help you with it.
In case in its description contains a [magic comment](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) your PR will be automatically attached to the issue:
```markdown
Resolves #<your issue ID here>
```
You can edit it if needed.
## Congratulations
You have successfully submitted your improvements! What is next?
- PRs will be reviewed by active maintainers, who will provide feedback and request changes as needed.
- The maintainers will request a review from _knsv_, if necessary.
- Once the PR is approved, the maintainers will merge the PR into the `develop` branch.
- When a release is ready, the `release/x.x.x` branch will be created, extensively tested and knsv will be in charge of the release process.
_knsv, Knut Sveidqvist_ is in charge of the final release process and the active maintainers are in charge of reviewing and merging most PRs.

31
packages/mermaid/src/docs/community/documentation.md
View File

@ -21,6 +21,12 @@ flowchart LR
source["Edit /packages/mermaid/src/docs"] -- automatic processing--> published["View /docs which will be publised on Official Website"]
```
## Enable Github Actions
```warning
So as to allow automatic compilation of documentation pages you have to enable github actions on your fork first
```
## Running the Documentation Website Locally
**[The mermaid documentation site](https://mermaid.js.org/) is powered by [Vitepress](https://vitepress.vuejs.org/).**
@ -35,7 +41,7 @@ pnpm --filter mermaid run docs:dev
or
```
```bash
cd packages/mermaid
pnpm docs:dev
```
@ -50,39 +56,32 @@ Open [http://localhost:3333/](http://localhost:3333/) in your browser.
## Format
The documentation is written in Markdown.
The documentation is written in Markdown. To get acquainted with its syntax [see the GitHub Markdown help page](https://help.github.com/en/github/writing-on-github/basic-writing-and-formatting-syntax).
You can use `note`, `tip`, `warning` and `danger` in triple backticks to add a note, tip, warning or danger box.
```danger
Do not use vitepress specific markdown syntax `::: warning` as it will not be processed correctly.
```
````markdown
```note
Note content
This is a note
```
```tip
Tip content
This is a tip
```
```warning
Warning content
This is a warning
```
```danger
Danger content
This is a danger alert
```
````
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).
_[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 from the branch of your fork.
## 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.**

46
packages/mermaid/src/docs/community/setup.md
View File

@ -6,17 +6,35 @@ Initial setup consists of 3 main steps:
flowchart LR
source --> requirements --> setup
requirements[Install the requirements]
source[Get the source code]
requirements[Install the requirements]
setup[Install packages]
```
## Choose Your Environment
## Get the Source Code
We support **development within Docker** environment along with **host setup**. You may choose it up to your preferences.
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 documentation, 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).
```bash
git clone git@github.com/your-fork/mermaid
```
Once you have cloned the repository onto your development machine, change into the `mermaid` project folder (the top level directory of the mermaid project repository)
```bash
cd mermaid
```
## Install Requirements
We support **development within Docker** environment along with **host setup**. You may choose it up to your preferences.
### Host
These are the tools we use for working with the code and documentation:
@ -39,27 +57,7 @@ echo $DISPLAY
If the `$DISPLAY` variable is not empty, then an X11 server is running. Otherwise you may need to install one.
## 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 documentation, 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).
```bash
git clone git@github.com/your-fork/mermaid
```
Once you have cloned the repository onto your development machine, change into the `mermaid` project folder (the top level directory of the mermaid project repository)
```bash
cd mermaid
```
## Setup
## Install packages
### Host

4
packages/mermaid/src/docs/community/workflow.md
View File

@ -114,8 +114,8 @@ Right now we are not following any strict rules about naming PRs. Give it a repr
In case in its description contains a [magic comment](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) your PR will be automatically attached to the issue:
```
Resolves #<your issue id here>
```markdown
Resolves #<your issue ID here>
```
You can edit it if needed.