contributing.md

17.1 KB567 lines

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