mirror of https://github.com/mermaid-js/mermaid.git synced 2025-01-14 06:43:25 +08:00

2023-12-19 01:36:43 +00:00

15 KiB

Raw Blame History

Warning

THIS IS AN AUTOGENERATED FILE. DO NOT EDIT.

Please edit the corresponding file in /packages/mermaid/src/docs/community/contributing.md.

Mermaid Contributing Guide

You decided to take part in the development? Welcome!

We were trying to make our guidelines for you as explicit and detailed as possible.

Initial Setup

Initial setup consists of 3 main steps:

flowchart LR
  source --> requirements --> setup

  source[Get the source code]
  requirements[Install the requirements]
  setup[Install packages]

Get the Source Code

In GitHub, you first fork a 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 to start contributing to the main project and its documentation, or search for other repositories.

Here is a GitHub document that gives an overview of the process.

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)

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 to manage node versions.
Node.js. volta install node
pnpm package manager. volta install pnpm
npx the packaged executor in npm. This is needed to install pnpm.

Docker

Install Docker. 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:

echo $DISPLAY

If the $DISPLAY variable is not empty, then an X11 server is running. Otherwise you may need to install one.

Install packages

Host

Run npx pnpm install. You will need npx for this because volta doesn't support it yet.

npx pnpm install # npx is required for first install

Docker

For development using Docker there is a self-documented run bash script, which provides convenient aliases for docker compose commands.

Make sure that ./run script is executable:

chmod +x run

💡 Tip To get detailed help simply type ./run or ./run help.

It also has short Development quick start guide embedded.

./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

pnpm test

Docker

./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–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:

  flowchart TB

  branch --> update --> submit --> review --> branch
  branch[Checkout a new branch]
  update[Make changes]
  submit[Submit a PR]
  review[Review and merge]

Checkout a New Branch

💡 Tip All new work should be based on the develop branch.

Make sure you have the most up-to-date version of the develop branch.

Check out the develop branch, then fetch or pull to update it:

git checkout develop
git fetch # or `git pull`

Create a new branch for your work:

git checkout -b docs/2910_update-contributing-guidelines

We use the following naming convention for branches:

[feature | bug | chore | docs]/[issue number]_[short-description]

You can always check current configuration of labelling and branch prefixes

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

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

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

npx pnpm run dev

Docker

./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 to run unit tests.

You can use the following command to run the unit tests:

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:

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:

Run pnpm dev to start the dev server
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:

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');
});

Update Documentation

💡 Tip Our documentation is managed in packages/mermaid/src/docs. Details on how to edit is in the documentation section

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.

Create another issue specifically for the documentation.
You will need to help with the PR, but definitely ask for help if you feel stuck. When it feels hard to write stuff out, explaining it to someone and having that person ask you clarifying questions can often be 80% of the work!

When in doubt, write up and submit what you can. It can be clarified and refined later. (With documentation, something is better than nothing!)

Contributing Documentation

If it is not in the documentation, it's like it never happened. Wouldn't that be sad? With all the effort that was put into the feature?

Where is the Documentation Located?

Warning

DO NOT CHANGE FILES IN /docs

The docs folder will be automatically generated when committing to packages/mermaid/src/docs and should not be edited manually.

Documentation is located in the packages/mermaid/src/docs folder. Just pick the right section and start typing.

The contents of mermaid.js.org are based on the docs from the master branch. Updates committed to the master branch are reflected in the Mermaid Docs once published.

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"]

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 is powered by Vitepress.

Start development server for the documentation site

Host

pnpm --filter mermaid run docs:dev

cd packages/mermaid
pnpm docs:dev

Docker

./run docs:dev

Open 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.

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.

```note
This is a note
```

```tip
This is a tip
```

```warning
This is a warning
```

```danger
This is a danger alert
```

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.

Submit your pull request

Note

Do not forget to push your changes
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 which will help you with it.

In case in its description contains a magic comment your PR will be automatically attached to the issue:

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.

15 KiB Raw Blame History Unescape Escape

THIS IS AN AUTOGENERATED FILE. DO NOT EDIT.

Please edit the corresponding file in /packages/mermaid/src/docs/community/contributing.md.

Mermaid Contributing Guide

Initial Setup

Get the Source Code

Install Requirements

Host

Docker

Install packages

Host

Docker

Verify Everything Works

Workflow

Checkout a New Branch

Contributing Code

Where is the code located?

Running Mermaid Locally

Make Changes

Write Tests

Unit Tests

Integration/End-to-End (e2e) tests

Update Documentation

Contributing Documentation

Where is the Documentation Located?

Enable Github Actions

Running the Documentation Website Locally

Format

Navigation

Submit your pull request

Congratulations

15 KiB

Raw Blame History