| 6dd74de | | | 1 | > **Warning** |
| 6dd74de | | | 2 | > |
| 6dd74de | | | 3 | > ## THIS IS AN AUTOGENERATED FILE. DO NOT EDIT. |
| 6dd74de | | | 4 | > |
| 6dd74de | | | 5 | > ## Please edit the corresponding file in [/packages/mermaid/src/docs/community/contributing.md](../../packages/mermaid/src/docs/community/contributing.md). |
| 6dd74de | | | 6 | |
| 6dd74de | | | 7 | # Mermaid Contributing Guide |
| 6dd74de | | | 8 | |
| 6dd74de | | | 9 | You decided to take part in the development? Welcome! |
| 6dd74de | | | 10 | |
| 6dd74de | | | 11 | We are trying to make our guidelines for you as explicit and detailed as possible. |
| 6dd74de | | | 12 | |
| 6dd74de | | | 13 | ## Initial Setup |
| 6dd74de | | | 14 | |
| 6dd74de | | | 15 | Initial setup consists of 3 main steps: |
| 6dd74de | | | 16 | |
| 6dd74de | | | 17 | ```mermaid |
| 6dd74de | | | 18 | flowchart LR |
| 6dd74de | | | 19 | source --> requirements --> setup |
| 6dd74de | | | 20 | |
| 6dd74de | | | 21 | source[Get the Source Code] |
| 6dd74de | | | 22 | requirements[Install the Requirements] |
| 6dd74de | | | 23 | setup[Install Packages] |
| 6dd74de | | | 24 | ``` |
| 6dd74de | | | 25 | |
| 6dd74de | | | 26 | ### Get the Source Code |
| 6dd74de | | | 27 | |
| 6dd74de | | | 28 | In GitHub, you first [**fork a mermaid repository**](https://github.com/mermaid-js/mermaid/fork) when you are going to make changes and submit pull requests. |
| 6dd74de | | | 29 | |
| 6dd74de | | | 30 | 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. |
| 6dd74de | | | 31 | |
| 6dd74de | | | 32 | > **💡 Tip** |
| 6dd74de | | | 33 | > [Here is a GitHub document that gives an overview of the process](https://docs.github.com/en/get-started/quickstart/fork-a-repo). |
| 6dd74de | | | 34 | |
| 6dd74de | | | 35 | ```bash |
| 6dd74de | | | 36 | git clone git@github.com/your-fork/mermaid |
| 6dd74de | | | 37 | ``` |
| 6dd74de | | | 38 | |
| 6dd74de | | | 39 | 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) |
| 6dd74de | | | 40 | |
| 6dd74de | | | 41 | ```bash |
| 6dd74de | | | 42 | cd mermaid |
| 6dd74de | | | 43 | ``` |
| 6dd74de | | | 44 | |
| 6dd74de | | | 45 | ### Install Requirements |
| 6dd74de | | | 46 | |
| 6dd74de | | | 47 | We support **development within Docker** environment along with **host setup**. You may choose it up to your preferences. |
| 6dd74de | | | 48 | |
| 6dd74de | | | 49 | **Host** |
| 6dd74de | | | 50 | |
| 6dd74de | | | 51 | These are the tools we use for working with the code and documentation: |
| 6dd74de | | | 52 | |
| 6dd74de | | | 53 | - [Node.js](https://nodejs.org/en/). |
| 6dd74de | | | 54 | - [pnpm](https://pnpm.io/) package manager. |
| 6dd74de | | | 55 | |
| 6dd74de | | | 56 | The following commands must be sufficient enough to start with: |
| 6dd74de | | | 57 | |
| 6dd74de | | | 58 | ```bash |
| 6dd74de | | | 59 | curl -fsSL https://get.pnpm.io/install.sh | sh - |
| 6dd74de | | | 60 | pnpm env use --global 20 |
| 6dd74de | | | 61 | ``` |
| 6dd74de | | | 62 | |
| 6dd74de | | | 63 | You may also need to reload `.shrc` or `.bashrc` afterwards. |
| 6dd74de | | | 64 | |
| 6dd74de | | | 65 | **Docker** |
| 6dd74de | | | 66 | |
| 6dd74de | | | 67 | [Install Docker](https://docs.docker.com/engine/install/). And that is pretty much all you need. |
| 6dd74de | | | 68 | |
| 6dd74de | | | 69 | Optionally, to run GUI (Cypress) within Docker you will also need an X11 server installed. |
| 6dd74de | | | 70 | You might already have it installed, so check this by running: |
| 6dd74de | | | 71 | |
| 6dd74de | | | 72 | ```bash |
| 6dd74de | | | 73 | echo $DISPLAY |
| 6dd74de | | | 74 | ``` |
| 6dd74de | | | 75 | |
| 6dd74de | | | 76 | If the `$DISPLAY` variable is not empty, then an X11 server is running. Otherwise you may need to install one. |
| 6dd74de | | | 77 | |
| 6dd74de | | | 78 | ### Install Packages |
| 6dd74de | | | 79 | |
| 6dd74de | | | 80 | **Host** |
| 6dd74de | | | 81 | |
| 6dd74de | | | 82 | Install packages: |
| 6dd74de | | | 83 | |
| 6dd74de | | | 84 | ```bash |
| 6dd74de | | | 85 | pnpm install |
| 6dd74de | | | 86 | ``` |
| 6dd74de | | | 87 | |
| 6dd74de | | | 88 | **Docker** |
| 6dd74de | | | 89 | |
| 6dd74de | | | 90 | For development using Docker there is a self-documented `run` bash script, which provides convenient aliases for `docker compose` commands. |
| 6dd74de | | | 91 | |
| 6dd74de | | | 92 | Make sure that `./run` script is executable: |
| 6dd74de | | | 93 | |
| 6dd74de | | | 94 | ```bash |
| 6dd74de | | | 95 | chmod +x run |
| 6dd74de | | | 96 | ``` |
| 6dd74de | | | 97 | |
| 6dd74de | | | 98 | > **💡 Tip** |
| 6dd74de | | | 99 | > To get detailed help simply type `./run` or `./run help`. |
| 6dd74de | | | 100 | > |
| 6dd74de | | | 101 | > It also has short _Development quick start guide_ embedded. |
| 6dd74de | | | 102 | |
| 6dd74de | | | 103 | Then install packages: |
| 6dd74de | | | 104 | |
| 6dd74de | | | 105 | ```bash |
| 6dd74de | | | 106 | ./run pnpm install |
| 6dd74de | | | 107 | ``` |
| 6dd74de | | | 108 | |
| 6dd74de | | | 109 | ### Verify Everything Works |
| 6dd74de | | | 110 | |
| 6dd74de | | | 111 | This step is optional, but it helps to make sure that everything in development branch was OK before you started making any changes. |
| 6dd74de | | | 112 | |
| 6dd74de | | | 113 | You can run the `test` script to verify that pnpm is working _and_ that the repository has been cloned correctly: |
| 6dd74de | | | 114 | |
| 6dd74de | | | 115 | **Host** |
| 6dd74de | | | 116 | |
| 6dd74de | | | 117 | ```bash |
| 6dd74de | | | 118 | pnpm test |
| 6dd74de | | | 119 | ``` |
| 6dd74de | | | 120 | |
| 6dd74de | | | 121 | **Docker** |
| 6dd74de | | | 122 | |
| 6dd74de | | | 123 | ```bash |
| 6dd74de | | | 124 | ./run pnpm test |
| 6dd74de | | | 125 | ``` |
| 6dd74de | | | 126 | |
| 6dd74de | | | 127 | The `test` script and others are in the top-level `package.json` file. |
| 6dd74de | | | 128 | |
| 6dd74de | | | 129 | All tests should run successfully without any errors or failures. |
| 6dd74de | | | 130 | |
| 6dd74de | | | 131 | > **Note** |
| 6dd74de | | | 132 | > You might see _lint_ or _formatting_ warnings. Those are ok during this step. |
| 6dd74de | | | 133 | |
| 6dd74de | | | 134 | ## Workflow |
| 6dd74de | | | 135 | |
| 6dd74de | | | 136 | Contributing process is very simple and straightforward: |
| 6dd74de | | | 137 | |
| 6dd74de | | | 138 | ```mermaid |
| 6dd74de | | | 139 | flowchart LR |
| 6dd74de | | | 140 | |
| 6dd74de | | | 141 | branch --> changes --> submit |
| 6dd74de | | | 142 | branch[Checkout a New Branch] |
| 6dd74de | | | 143 | changes[Make Changes] |
| 6dd74de | | | 144 | submit[Submit a PR] |
| 6dd74de | | | 145 | ``` |
| 6dd74de | | | 146 | |
| 6dd74de | | | 147 | Mermaid uses a [Git Flow](https://guides.github.com/introduction/flow/)–inspired approach to branching. |
| 6dd74de | | | 148 | |
| 6dd74de | | | 149 | Development is done in the `develop` branch. |
| 6dd74de | | | 150 | |
| 6dd74de | | | 151 | ```mermaid |
| 6dd74de | | | 152 | --- |
| 6dd74de | | | 153 | config: |
| 6dd74de | | | 154 | gitGraph: |
| 6dd74de | | | 155 | mainBranchName: develop |
| 6dd74de | | | 156 | --- |
| 6dd74de | | | 157 | gitGraph LR: |
| 6dd74de | | | 158 | commit |
| 6dd74de | | | 159 | commit |
| 6dd74de | | | 160 | branch "docs/2910_update-guidelines" order: 1 |
| 6dd74de | | | 161 | commit |
| 6dd74de | | | 162 | commit |
| 6dd74de | | | 163 | commit |
| 6dd74de | | | 164 | checkout develop |
| 6dd74de | | | 165 | merge "docs/2910_update-guidelines" |
| 6dd74de | | | 166 | commit |
| 6dd74de | | | 167 | ``` |
| 6dd74de | | | 168 | |
| 6dd74de | | | 169 | To prepare a new version for release the maintainers create a `release/vX.X.X` branch from `develop` for testing. Once the release happens we add a tag to the `release` branch and merge it with `master`. The live product and on-line documentation are what is in the `master` branch. |
| 6dd74de | | | 170 | |
| 6dd74de | | | 171 | ## Checkout a New Branch |
| 6dd74de | | | 172 | |
| 6dd74de | | | 173 | > **💡 Tip** |
| 6dd74de | | | 174 | > All new work should be based on the `develop` branch. |
| 6dd74de | | | 175 | |
| 6dd74de | | | 176 | Make sure you have the most up-to-date version of the `develop` branch. |
| 6dd74de | | | 177 | |
| 6dd74de | | | 178 | Check out the `develop` branch, then `fetch` or `pull` to update it: |
| 6dd74de | | | 179 | |
| 6dd74de | | | 180 | ```bash |
| 6dd74de | | | 181 | git checkout develop |
| 6dd74de | | | 182 | git fetch # or `git pull` |
| 6dd74de | | | 183 | ``` |
| 6dd74de | | | 184 | |
| 6dd74de | | | 185 | Create a new branch for your work: |
| 6dd74de | | | 186 | |
| 6dd74de | | | 187 | ```bash |
| 6dd74de | | | 188 | git checkout -b docs/2910_update-contributing-guidelines |
| 6dd74de | | | 189 | ``` |
| 6dd74de | | | 190 | |
| 6dd74de | | | 191 | We use the following naming convention for branches: |
| 6dd74de | | | 192 | |
| 6dd74de | | | 193 | ```txt |
| 6dd74de | | | 194 | [feature | bug | chore | docs]/[issue number]_[short-description] |
| 6dd74de | | | 195 | ``` |
| 6dd74de | | | 196 | |
| 6dd74de | | | 197 | You can always check current [configuration of labelling and branch prefixes](https://github.com/mermaid-js/mermaid/blob/develop/.github/pr-labeler.yml) |
| 6dd74de | | | 198 | |
| 6dd74de | | | 199 | - The first part is the **type** of change: a `feature`, `bug`, `chore`, `docs` |
| 6dd74de | | | 200 | - followed by a **slash** (`/`),which helps to group like types together in many git tools |
| 6dd74de | | | 201 | - followed by the **issue number**, e.g. `2910` |
| 6dd74de | | | 202 | - followed by an **underscore** (`_`) |
| 6dd74de | | | 203 | - followed by a **short description** with dashes (`-`) or underscores (`_`) instead of spaces |
| 6dd74de | | | 204 | |
| 6dd74de | | | 205 | ```mermaid |
| 6dd74de | | | 206 | flowchart LR |
| 6dd74de | | | 207 | feature --> slash |
| 6dd74de | | | 208 | bug --> slash |
| 6dd74de | | | 209 | chore --> slash |
| 6dd74de | | | 210 | docs --> slash |
| 6dd74de | | | 211 | slash --> 2945 --> underscore |
| 6dd74de | | | 212 | slash --> 1123 --> underscore |
| 6dd74de | | | 213 | underscore --> short_description_1 |
| 6dd74de | | | 214 | underscore --> short_description_2 |
| 6dd74de | | | 215 | |
| 6dd74de | | | 216 | underscore["_"] |
| 6dd74de | | | 217 | slash["/"] |
| 6dd74de | | | 218 | |
| 6dd74de | | | 219 | short_description_1["state-diagram-new-arrow-florbs"] |
| 6dd74de | | | 220 | short_description_2["fix_random_ugly_red_text"] |
| 6dd74de | | | 221 | ``` |
| 6dd74de | | | 222 | |
| 6dd74de | | | 223 | 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. |
| 6dd74de | | | 224 | |
| 6dd74de | | | 225 | > **Note** |
| 6dd74de | | | 226 | > A new feature described in issue 2945 that adds a new arrow type called 'florbs' to state diagrams |
| 6dd74de | | | 227 | > |
| 6dd74de | | | 228 | > `feature/2945_state-diagram-new-arrow-florbs` |
| 6dd74de | | | 229 | |
| 6dd74de | | | 230 | > **💡 Tip** |
| 6dd74de | | | 231 | > A bug described in issue 1123 that causes random ugly red text in multiple diagram types |
| 6dd74de | | | 232 | > |
| 6dd74de | | | 233 | > `bug/1123_fix_random_ugly_red_text` |
| 6dd74de | | | 234 | |
| 6dd74de | | | 235 | ## Contributing Code |
| 6dd74de | | | 236 | |
| 6dd74de | | | 237 | Code is the heart of every software project. We strive to make it better. Who if not us? |
| 6dd74de | | | 238 | |
| 6dd74de | | | 239 | ### Where is the Code Located? |
| 6dd74de | | | 240 | |
| 6dd74de | | | 241 | The core of Mermaid is located under `packages/mermaid/src`. |
| 6dd74de | | | 242 | |
| 6dd74de | | | 243 | ### Building Mermaid Locally |
| 6dd74de | | | 244 | |
| 6dd74de | | | 245 | **Host** |
| 6dd74de | | | 246 | |
| 6dd74de | | | 247 | ```bash |
| 6dd74de | | | 248 | pnpm run build |
| 6dd74de | | | 249 | ``` |
| 6dd74de | | | 250 | |
| 6dd74de | | | 251 | **Docker** |
| 6dd74de | | | 252 | |
| 6dd74de | | | 253 | ```bash |
| 6dd74de | | | 254 | ./run build |
| 6dd74de | | | 255 | ``` |
| 6dd74de | | | 256 | |
| 6dd74de | | | 257 | This will build the Mermaid library and the documentation site. |
| 6dd74de | | | 258 | |
| 6dd74de | | | 259 | ### Running Mermaid Locally |
| 6dd74de | | | 260 | |
| 6dd74de | | | 261 | **Host** |
| 6dd74de | | | 262 | |
| 6dd74de | | | 263 | ```bash |
| 6dd74de | | | 264 | pnpm run dev |
| 6dd74de | | | 265 | ``` |
| 6dd74de | | | 266 | |
| 6dd74de | | | 267 | **Docker** |
| 6dd74de | | | 268 | |
| 6dd74de | | | 269 | ```bash |
| 6dd74de | | | 270 | ./run dev |
| 6dd74de | | | 271 | ``` |
| 6dd74de | | | 272 | |
| 6dd74de | | | 273 | After starting the dev server open <http://localhost:9000> in your browser. |
| 6dd74de | | | 274 | |
| 6dd74de | | | 275 | Now you are ready to make your changes! |
| 6dd74de | | | 276 | |
| 6dd74de | | | 277 | Note: By default, the Mermaid service will run on port 9000. To use a different port, change the environment variable `MERMAID_PORT` in the file `.env`. You should only need to do this if you are using port 9000 to run other projects. |
| 6dd74de | | | 278 | |
| 6dd74de | | | 279 | ### Make Changes |
| 6dd74de | | | 280 | |
| 6dd74de | | | 281 | Have a look at <http://localhost:9000>. There is a list of demos that can be used to see and test your changes. |
| 6dd74de | | | 282 | |
| 6dd74de | | | 283 | 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. |
| 6dd74de | | | 284 | |
| 6dd74de | | | 285 | That will be served at <http://localhost:9000/dev/your-file-name.html>. |
| 6dd74de | | | 286 | After making code changes, the dev server will rebuild the mermaid library and automatically reload the page. |
| 6dd74de | | | 287 | |
| 6dd74de | | | 288 | Edit files in `packages/mermaid/src` as required. |
| 6dd74de | | | 289 | |
| 6dd74de | | | 290 | ### Write Tests |
| 6dd74de | | | 291 | |
| 6dd74de | | | 292 | 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). |
| 6dd74de | | | 293 | |
| 6dd74de | | | 294 | Just as important, the tests act as _specifications:_ they specify what the code does (or should do). |
| 6dd74de | | | 295 | 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. |
| 6dd74de | | | 296 | |
| 6dd74de | | | 297 | 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. |
| 6dd74de | | | 298 | (If there had been a test for the situation, the bug never would have happened in the first place.) |
| 6dd74de | | | 299 | You may need to change existing tests if they were inaccurate. |
| 6dd74de | | | 300 | |
| 6dd74de | | | 301 | 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. |
| 6dd74de | | | 302 | |
| 6dd74de | | | 303 | #### Unit Tests |
| 6dd74de | | | 304 | |
| 6dd74de | | | 305 | Unit tests are tests that test a single function or module. They are the easiest to write and the fastest to run. |
| 6dd74de | | | 306 | |
| 6dd74de | | | 307 | Unit tests are mandatory for all code except the layout tests. (The layouts are tested with integration tests.) |
| 6dd74de | | | 308 | |
| 6dd74de | | | 309 | We use [Vitest](https://vitest.dev) to run unit tests. |
| 6dd74de | | | 310 | |
| 6dd74de | | | 311 | **Host** |
| 6dd74de | | | 312 | |
| 6dd74de | | | 313 | You can use the following command to run the unit tests: |
| 6dd74de | | | 314 | |
| 6dd74de | | | 315 | ```sh |
| 6dd74de | | | 316 | pnpm test |
| 6dd74de | | | 317 | ``` |
| 6dd74de | | | 318 | |
| 6dd74de | | | 319 | 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: |
| 6dd74de | | | 320 | |
| 6dd74de | | | 321 | ```sh |
| 6dd74de | | | 322 | pnpm test:watch |
| 6dd74de | | | 323 | ``` |
| 6dd74de | | | 324 | |
| 6dd74de | | | 325 | **Docker** |
| 6dd74de | | | 326 | |
| 6dd74de | | | 327 | When using Docker prepend your command with `./run`: |
| 6dd74de | | | 328 | |
| 6dd74de | | | 329 | ```sh |
| 6dd74de | | | 330 | ./run pnpm test |
| 6dd74de | | | 331 | ``` |
| 6dd74de | | | 332 | |
| 6dd74de | | | 333 | ##### Testing the DOM |
| 6dd74de | | | 334 | |
| 6dd74de | | | 335 | One can use `jsdomIt` to test any part of Mermaid that interacts with the DOM, as long as it is not related to the layout. |
| 6dd74de | | | 336 | |
| 6dd74de | | | 337 | The function `jsdomIt` ([developed in utils.ts](../../tests/util.ts)) overrides `it` from `vitest`, and creates a pseudo-browser environment that works almost like the real deal for the duration of the test. It uses JSDOM to create a DOM, and adds objects `window` and `document` to `global` to mock the browser environment. |
| 6dd74de | | | 338 | |
| 6dd74de | | | 339 | > \[!NOTE] |
| 6dd74de | | | 340 | > The layout cannot work in `jsdomIt` tests because JSDOM has no rendering engine, hence the pseudo-browser environment. |
| 6dd74de | | | 341 | |
| 6dd74de | | | 342 | Example : |
| 6dd74de | | | 343 | |
| 6dd74de | | | 344 | ```typescript |
| 6dd74de | | | 345 | import { ensureNodeFromSelector, jsdomIt } from './tests/util.js'; |
| 6dd74de | | | 346 | |
| 6dd74de | | | 347 | jsdomIt('should add element "thing" in the SVG', ({ svg }) => { |
| 6dd74de | | | 348 | // Code in this block runs in a pseudo-browser environment |
| 6dd74de | | | 349 | addThing(svg); // The svg item is the D3 selection of the SVG node |
| 6dd74de | | | 350 | const svgNode = ensureNodeFromSelector('svg'); // Retrieve the DOM node using the DOM API |
| 6dd74de | | | 351 | expect(svgNode.querySelector('thing')).not.toBeNull(); // Test the structure of the SVG |
| 6dd74de | | | 352 | }); |
| 6dd74de | | | 353 | ``` |
| 6dd74de | | | 354 | |
| 6dd74de | | | 355 | They can be used to test any method that interacts with the DOM, including for testing renderers. For renderers, additional integration testing is necessary to test the layout though. |
| 6dd74de | | | 356 | |
| 6dd74de | | | 357 | #### Integration / End-to-End (E2E) Tests |
| 6dd74de | | | 358 | |
| 6dd74de | | | 359 | These test the rendering and visual appearance of the diagrams. |
| 6dd74de | | | 360 | |
| 6dd74de | | | 361 | 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! |
| 6dd74de | | | 362 | |
| 6dd74de | | | 363 | To start working with the E2E tests: |
| 6dd74de | | | 364 | |
| 6dd74de | | | 365 | **Host** |
| 6dd74de | | | 366 | |
| 6dd74de | | | 367 | - Run `pnpm dev` to start the dev server |
| 6dd74de | | | 368 | - Start **Cypress** by running `pnpm cypress:open` |
| 6dd74de | | | 369 | |
| 6dd74de | | | 370 | **Docker** |
| 6dd74de | | | 371 | |
| 6dd74de | | | 372 | - Enable local connections for x11 server `xhost +local:` |
| 6dd74de | | | 373 | - Run `./run pnpm dev` to start the dev server |
| 6dd74de | | | 374 | - Start **Cypress** by running `./run pnpm cypress:open --project .` |
| 6dd74de | | | 375 | |
| 6dd74de | | | 376 | 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. |
| 6dd74de | | | 377 | |
| 6dd74de | | | 378 | 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. |
| 6dd74de | | | 379 | |
| 6dd74de | | | 380 | This is what a rendering test looks like: |
| 6dd74de | | | 381 | |
| 6dd74de | | | 382 | ```js |
| 6dd74de | | | 383 | it('should render forks and joins', () => { |
| 6dd74de | | | 384 | imgSnapshotTest( |
| 6dd74de | | | 385 | ` |
| 6dd74de | | | 386 | stateDiagram |
| 6dd74de | | | 387 | state fork_state <<fork>> |
| 6dd74de | | | 388 | [*] --> fork_state |
| 6dd74de | | | 389 | fork_state --> State2 |
| 6dd74de | | | 390 | fork_state --> State3 |
| 6dd74de | | | 391 | |
| 6dd74de | | | 392 | state join_state <<join>> |
| 6dd74de | | | 393 | State2 --> join_state |
| 6dd74de | | | 394 | State3 --> join_state |
| 6dd74de | | | 395 | join_state --> State4 |
| 6dd74de | | | 396 | State4 --> [*] |
| 6dd74de | | | 397 | `, |
| 6dd74de | | | 398 | { logLevel: 0 } |
| 6dd74de | | | 399 | ); |
| 6dd74de | | | 400 | }); |
| 6dd74de | | | 401 | ``` |
| 6dd74de | | | 402 | |
| 6dd74de | | | 403 | <!-- **_[TODO - running the tests against what is expected in development. ]_** --> |
| 6dd74de | | | 404 | |
| 6dd74de | | | 405 | <!-- **_[TODO - how to generate new screenshots]_** --> |
| 6dd74de | | | 406 | |
| 6dd74de | | | 407 | ### Update Documentation |
| 6dd74de | | | 408 | |
| 6dd74de | | | 409 | > **💡 Tip** |
| 6dd74de | | | 410 | > Our documentation is managed in `packages/mermaid/src/docs`. Details on how to edit is in the [documentation section](#contributing-documentation) |
| 6dd74de | | | 411 | |
| 6dd74de | | | 412 | 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. |
| 6dd74de | | | 413 | Likewise, if users don't know that there is a new feature that you've implemented, it will forever remain unknown and unused. |
| 6dd74de | | | 414 | |
| 6dd74de | | | 415 | The documentation has to be updated for users to know that things have been changed and added! |
| 6dd74de | | | 416 | 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. |
| 6dd74de | | | 417 | |
| 6dd74de | | | 418 | eg: `# Feature Name (v<MERMAID_RELEASE_VERSION>+)` |
| 6dd74de | | | 419 | |
| 6dd74de | | | 420 | We know it can sometimes be hard to code _and_ write user documentation. |
| 6dd74de | | | 421 | |
| 6dd74de | | | 422 | Create another issue specifically for the documentation. |
| 6dd74de | | | 423 | You will need to help with the PR, but definitely ask for help if you feel stuck. |
| 6dd74de | | | 424 | 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! |
| 6dd74de | | | 425 | |
| 6dd74de | | | 426 | When in doubt, write up and submit what you can. It can be clarified and refined later. (With documentation, something is better than nothing!) |
| 6dd74de | | | 427 | |
| 6dd74de | | | 428 | ## Contributing Documentation |
| 6dd74de | | | 429 | |
| 6dd74de | | | 430 | 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? |
| 6dd74de | | | 431 | |
| 6dd74de | | | 432 | ### Where is the Documentation Located? |
| 6dd74de | | | 433 | |
| 6dd74de | | | 434 | > **Warning** |
| 6dd74de | | | 435 | > DO NOT CHANGE FILES IN `/docs` |
| 6dd74de | | | 436 | > |
| 6dd74de | | | 437 | > The `docs` folder will be automatically generated when committing to `packages/mermaid/src/docs` and **should not** be edited manually. |
| 6dd74de | | | 438 | |
| 6dd74de | | | 439 | Documentation is located in the [`packages/mermaid/src/docs`](https://github.com/mermaid-js/mermaid/tree/develop/packages/mermaid/src/docs) folder. Just pick the right section and start typing. |
| 6dd74de | | | 440 | |
| 6dd74de | | | 441 | 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. |
| 6dd74de | | | 442 | |
| 6dd74de | | | 443 | ```mermaid-example |
| 6dd74de | | | 444 | flowchart LR |
| 6dd74de | | | 445 | classDef default fill:#fff,color:black,stroke:black |
| 6dd74de | | | 446 | |
| 6dd74de | | | 447 | source["Edit /packages/mermaid/src/docs"] -- automatic processing--> published["View /docs which will be published on Official Website"] |
| 6dd74de | | | 448 | ``` |
| 6dd74de | | | 449 | |
| 6dd74de | | | 450 | ```mermaid |
| 6dd74de | | | 451 | flowchart LR |
| 6dd74de | | | 452 | classDef default fill:#fff,color:black,stroke:black |
| 6dd74de | | | 453 | |
| 6dd74de | | | 454 | source["Edit /packages/mermaid/src/docs"] -- automatic processing--> published["View /docs which will be published on Official Website"] |
| 6dd74de | | | 455 | ``` |
| 6dd74de | | | 456 | |
| 6dd74de | | | 457 | ### Running the Documentation Website Locally |
| 6dd74de | | | 458 | |
| 6dd74de | | | 459 | **[The mermaid documentation site](https://mermaid.js.org/) is powered by [Vitepress](https://vitepress.vuejs.org/).** |
| 6dd74de | | | 460 | |
| 6dd74de | | | 461 | Start development server for the documentation site |
| 6dd74de | | | 462 | |
| 6dd74de | | | 463 | **Host** |
| 6dd74de | | | 464 | |
| 6dd74de | | | 465 | ```bash |
| 6dd74de | | | 466 | pnpm --filter mermaid run docs:dev |
| 6dd74de | | | 467 | ``` |
| 6dd74de | | | 468 | |
| 6dd74de | | | 469 | or |
| 6dd74de | | | 470 | |
| 6dd74de | | | 471 | ```bash |
| 6dd74de | | | 472 | cd packages/mermaid |
| 6dd74de | | | 473 | pnpm docs:dev |
| 6dd74de | | | 474 | ``` |
| 6dd74de | | | 475 | |
| 6dd74de | | | 476 | **Docker** |
| 6dd74de | | | 477 | |
| 6dd74de | | | 478 | ```bash |
| 6dd74de | | | 479 | ./run docs:dev |
| 6dd74de | | | 480 | ``` |
| 6dd74de | | | 481 | |
| 6dd74de | | | 482 | Open <http://localhost:3333/> in your browser. |
| 6dd74de | | | 483 | |
| 6dd74de | | | 484 | ### Formatting |
| 6dd74de | | | 485 | |
| 6dd74de | | | 486 | 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). |
| 6dd74de | | | 487 | |
| 6dd74de | | | 488 | You can use `note`, `tip`, `warning` and `danger` in triple backticks to add a note, tip, warning or danger box. |
| 6dd74de | | | 489 | |
| 6dd74de | | | 490 | > **‼️ Danger** |
| 6dd74de | | | 491 | > Do not use vitepress specific markdown syntax `::: warning` as it will not be processed correctly. |
| 6dd74de | | | 492 | |
| 6dd74de | | | 493 | Here are a few examples: |
| 6dd74de | | | 494 | |
| 6dd74de | | | 495 | ````markdown |
| 6dd74de | | | 496 | ```note |
| 6dd74de | | | 497 | This is a note |
| 6dd74de | | | 498 | ``` |
| 6dd74de | | | 499 | |
| 6dd74de | | | 500 | ```tip |
| 6dd74de | | | 501 | This is a tip |
| 6dd74de | | | 502 | ``` |
| 6dd74de | | | 503 | |
| 6dd74de | | | 504 | ```warning |
| 6dd74de | | | 505 | This is a warning |
| 6dd74de | | | 506 | ``` |
| 6dd74de | | | 507 | |
| 6dd74de | | | 508 | ```danger |
| 6dd74de | | | 509 | This is a danger alert |
| 6dd74de | | | 510 | ``` |
| 6dd74de | | | 511 | ```` |
| 6dd74de | | | 512 | |
| 6dd74de | | | 513 | > **Note** |
| 6dd74de | | | 514 | > This is a note |
| 6dd74de | | | 515 | |
| 6dd74de | | | 516 | > **💡 Tip** |
| 6dd74de | | | 517 | > This is a tip |
| 6dd74de | | | 518 | |
| 6dd74de | | | 519 | > **Warning** |
| 6dd74de | | | 520 | > This is a warning |
| 6dd74de | | | 521 | |
| 6dd74de | | | 522 | > **‼️ Danger** |
| 6dd74de | | | 523 | > This is a danger alert |
| 6dd74de | | | 524 | |
| 6dd74de | | | 525 | ### Navigation |
| 6dd74de | | | 526 | |
| 6dd74de | | | 527 | If you want to propose changes to how the documentation is _organized_, such as adding a new section or re-arranging or renaming a section, you must update the **sidebar navigation**, which is defined in [the vitepress config](../.vitepress/config.ts). The same goes for **topbar**. |
| 6dd74de | | | 528 | |
| 6dd74de | | | 529 | ### Build Docs |
| 6dd74de | | | 530 | |
| 6dd74de | | | 531 | The content of `/docs` folder is built with GitHub Actions. |
| 6dd74de | | | 532 | |
| 6dd74de | | | 533 | > **Warning** |
| 6dd74de | | | 534 | > So as to allow automatic compilation of documentation pages you have to enable GitHub Actions on your fork first |
| 6dd74de | | | 535 | |
| 6dd74de | | | 536 | ## Submit your pull request |
| 6dd74de | | | 537 | |
| 6dd74de | | | 538 | > **Note** |
| 6dd74de | | | 539 | > Do not forget to push your changes |
| 6dd74de | | | 540 | > |
| 6dd74de | | | 541 | > ```bash |
| 6dd74de | | | 542 | > git push -u origin docs/2910_update-guidelines |
| 6dd74de | | | 543 | > ``` |
| 6dd74de | | | 544 | |
| 6dd74de | | | 545 | We make all changes via Pull Requests (PRs). Open a new one. |
| 6dd74de | | | 546 | |
| 6dd74de | | | 547 | 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. |
| 6dd74de | | | 548 | |
| 6dd74de | | | 549 | 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: |
| 6dd74de | | | 550 | |
| 6dd74de | | | 551 | ```markdown |
| 6dd74de | | | 552 | Resolves #<your issue ID here> |
| 6dd74de | | | 553 | ``` |
| 6dd74de | | | 554 | |
| 6dd74de | | | 555 | ## Congratulations |
| 6dd74de | | | 556 | |
| 6dd74de | | | 557 | You have successfully submitted your improvements! What is next? |
| 6dd74de | | | 558 | |
| 6dd74de | | | 559 | - PRs will be reviewed by active maintainers, who will provide feedback and request changes as needed. |
| 6dd74de | | | 560 | - The maintainers will request a review from _knsv_, if necessary. |
| 6dd74de | | | 561 | - Once the PR is approved, the maintainers will merge the PR into the `develop` branch. |
| 6dd74de | | | 562 | - 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. |
| 6dd74de | | | 563 | |
| 6dd74de | | | 564 | Thanks for you help! |
| 6dd74de | | | 565 | |
| 6dd74de | | | 566 | <!--- cspell:ignore florbs ---> |