* develop:
build(docs): handle YAML edgecases in markdown
run pnpm lint:fix
Update cypress/helpers/util.ts
change deprecated `btoa` into `Buffer.from`
allow ts extension imports in cypress ts files
build(docs): allow using custom `editLink`
build(docs): add `editLink: ` to MD frontmatter
build(docs): run remark plugins on MermaidConfig
Fix import file extension
Batch by commit
resolve lint issues for `no-inferrable-types`
fix wrong config paramater in some cypress spec
convert cypress/helpers/util.js into ts
convert file from js into ts
Add a YAML front-matter entry called `editLink` to Markdown files in
Vitepress, e.g.
```markdown
---
editLink: "https://github.com/mermaid-js/mermaid/edit/develop/packages/mermaid/src/schemas/config.schema.yaml"
---
Here is my markdown file!
```
Although Vitepress doesn't officially support adding a URL as a
`editLink:` YAML front-matter, we can add a custom `editLink` function
to our Vitepress config that does allow it.
This reverts commit 063cb124cd.
This file was originally added to test whether the new implementation
of the default config in
`packages/mermaid/src/schemas/config.schema.yaml` matched the old
existing default config in `packages/mermaid/src/oldDefaultConfig.ts`,
and this test is no longer needed.
This test was accidentally removed by a bad merge commit, see
29291c89 (Merge branch 'develop' into pr/aloisklink/4112, 2023-07-06).
This test checks whether the default config defined in the
`config.schema.yaml` file matches the old default config defined in
`oldDefaultConfig.ts`.
Fixes: 29291c8901
* develop: (293 commits)
chore: Remove lint warnings in example-diagram
chore: Reduce codecov pushes
Turn off codecov project status check
build(docs): fix links to `config.schema.json`
ci(lint): check if MermaidConfig types are in sync
docs: add link to mermaid config docs in sidebar
test(config): add temp test for defaultConfig
build(types): create types from config JSON Schema
build(types): add script to generate Config types
build(docs): build JSON Schema docs
build: use vite to get default mermaid config
feat: add Mermaid Config in JSON Schema format
docs: add support for ```regexp``` code blocks
test: test partial QuadrantChartConfig options
test: fix types in `config.spec.ts`
style: fix lint issues in src/config.spec.ts
test: rename src/config.spec.js to config.spec.ts
fix(quadrant): make quadrant options optional
fix lint
update homepage community link
...
Fix the link in some Mermaid Config markdown documentation,
which previously pointed to `src/schemas/config.schema.yaml`,
which went nowhere.
Now, these links point to:
- config.schema.json (i.e. the generated JSON file, not YAML)
- links are relative to the markdown documentation
We also needed to store the `schema.json` file in the Vitepress
`public/` folder, as Vitepress otherwise doesn't bundle `.json` files
properly, when running `vitepress build src/vitepress`.
Add a CI check that runs
`pnpm run --filter mermaid types:verify-config` and checks whether
the MermaidConfig TypeScript types are in sync with the MermaidConfig
JSON Schema.
Adds a temporary test to ensure that the new defaultConfig,
generated by Vite automatically from the `MermaidConfig` JSON Schema,
has the same values as the old defaultConfig
(taken from
38013de711/packages/mermaid/src/defaultConfig.ts)
The only minor difference seems to be that:
- `gitGraph` now has a default `useMaxWidth: false` option
(previously used to be `undefined`),
- `class` now has a `htmlLabels` value of `false` instead of `undefined`.
Add script `packages/mermaid/scripts/create-types-from-json-schema.mts`
to automatically generate the TypeScript definition for `MermaidConfig`
from the `MermaidConfig` JSON Schema at
`packages/mermaid/src/schemas/config.schema.yaml`.
To do this, we are using this library
[`json-schema-to-typescript`][1], which is also used by Webpack to
generate their types from their JSON Schema.
In order to make sure that this isn't a breaking change, the script
makes all fields **optional**, as that is what the original typescript
file has.
Additionally, I've put in some custom logic into the script, so that
the exact same order is used for the TypeScript file, to make the
`git diff` easier to review. In the future, we can remove this custom
logic, once we no longer need to worry about `git merge` conflicts.
[1]: https://github.com/bcherny/json-schema-to-typescript
Automatically build documentation for JSON Schema.
This is only built when running with `--vitepress`,
as it currently produces loads of markdown files, which I feel like
we shouldn't be committing.
This currently manually uses some internal `jsonschema2md` functions
so that we can manually control the Markdown output.
Adds a vitepress JsonSchema plugin that automatically loads
the Mermaid Config JSON Schema from a .schema.yaml file and
gets the default values from it.
Add a JSON Schema file (in YAML) for the MermaidConfig.
This JSON Schema file follows [JSON Schema 2019-09][1], with some slight
modifications to work with:
- [json-schema-to-typescript][2]
The `tsType` keyword is used to override the generated TypeScript
type, when it doesn't match the JSON Schema type.
This is used in two cases:
- when the current type cannot be represented in JSON Schema
(e.g. `FontCalculator`, which is a function)
- when the JSON Schema type is narrower than the TypeScript type.
Currently, many enums types are listed as `string` in TypeScript,
but json-schema-to-typescript converts them to `"val1" | "val2"`.
I've manually set them to `string | "val1" | "val2"` to avoid
causing a breaking change in the TypeScript types. We should
remove these in a future major version of TypeScript.
- [@adobe/jsonschema2md][3]
The `meta:enum` keyword is used to add documentation for specific enum
values.
[1]: https://json-schema.org/draft/2019-09/release-notes.html
[2]: https://www.npmjs.com/package/json-schema-to-typescript
[3]: https://www.npmjs.com/package/@adobe/jsonschema2md
Currently, shiki doesn't support code-blocks that use the regexp
language, which means vitepress throws an error on them:
```regexp
^([1-9][0-9]*)(minute|hour|day|week|month)$
```
As a hack until shiki supports them, I've just modified them to get
converted into JavaScript RegEx literal code-blocks, e.g.:
```javascript
/^([1-9][0-9]*)(minute|hour|day|week|month)$/
```
Make the types of the options in QuadrantChartConfig in the
MermaidConfig optional. All of these (except for the values in
`BaseDiagramConfig`) will be automatically set to their
default values, so they're optional from a user perspective.
Replace the TypeScript `enum {a = "a", b = "b"}` types with
TypeScript's literal types (e.g. `"a" | "b"`).
This is because TypeScript enums are
[_not_ a type-level addition to JavaScript][1], and even the official
TypeScript docs say to be careful when using.
[1]: https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#enums
Added cypress container (from their official image),
may be reconsidered later to choose our own
The only minor problem is node JS version mistmatch
package.json 18.16.0
docker-compose mermaid 18.16.1
docker-compose cypress 18.16.0
Host option in cypress docker container must be removed
in favor of possible configuration option.
http://localhost:9000 are currently hard-coded, that is bad
Updated ./run script with better documentation
and added some styles too it as well
Started sankey.spec.js as an example
Tooltip is an object that gets reset to an array. It is then looked up for properties without guard, causing array functions like "length" and "constructor" to run into undefined behvaior.
- add types for parameter and returned value and variables
- change the deperated `unescape` into `decodeURIComponent`
- create `CypressConfig` and `CypressMermaidConfig` and `CodeObject` types
- add default value for some parameter
- remove @ts-ignore comments
- rename vitest test and describe title
- remove unnecessary types, e.i, `null` and `number`
- clean `addSVGa11yTitleDescription` and `setA11yDiagramInfo` functions
* develop: (783 commits)
chore(deps): update all minor dependencies
chore: Run codecov based on E2E test status
change REAMDME.md coverage from coveralls into codecov
Add codecov.yaml
Upload E2E
set normal mode for vitest coverage
Fix path name
Add codecov to unit tests
Add codecov to E2E
chore: Add coverage scripts
chore: add excludes
chore: update deps
Merge coverages
Add coverage paths
Rebuild
chore: update pnpm
Add coverage for E2E tests
rename plugin variable into info in infoDetector.ts
remove cypress/platform/index.html
update pnpm-lock.yaml
...
* develop: (43 commits)
rename plugin variable into info in infoDetector.ts
remove cypress/platform/index.html
update pnpm-lock.yaml
indent info.html files
update pnpm-lock.yaml
remove empty options in cypress info.spec.ts
format and add theme to cypress info.html
convert the cypress info.spec.js into ts
add messing timeline and info demoes links
change infoDb db export
remove default export in info files
resolve db import in info.spec.ts
remove assigned variables to their variables and export db without default
use object destructuring for getConfig in infoRenderer
move default_info_db into infoDbOF
remove id and diagram assigning in info loader
assign returned variables to their variables
remove handled `ts-ignore` in info diagram
handle optional `.styles`
add info fields interface
...
* develop: (815 commits)
Move filetype Recommendations to the top
Update docs
Update integrations.md per review
Disable coveralls
Update coveralls
Ignore bundlephobia
Update docs
strawman extension and mime type docs
Update docs
Rename info to note
Rename "info" to "note"
Update all patch dependencies
Fix Directives Documentation
Run docs:build
Update tutorial link
Run build
Fix link to Tutorials from n00b-overview page
Correct timeline spelling
UPdated version to 10.2.3
Remove old changelog
...
Updated lintignore and move dockerfile to .dev
Fix
Updated contributing
Fixing GA
Fix contributing.md
Fixing issues after review
No need to change .eslintignore
there is no need for matching, capturing results, and validating nullablity
just using `.test` would be enough and significantly faster
for more info, see https://stackoverflow.com/10940138/16476610
* develop:
Update docs
Rename info to note
Rename "info" to "note"
Update all patch dependencies
Fix Directives Documentation
Update tutorial link
Run build
Fix link to Tutorials from n00b-overview page
UPdated version to 10.2.3
Remove old changelog
Remove old changelog
Setting version to 10.2.2
#4446 Improved regular expression
#4446 Updating the cleanup criteria
#4438 Reverted to the changes from #4285
Fix download
Fix compile error in docs.
Fix Contributor link in homepage
Update docs
Add hint on "flowchart" and "graph" (and some more styling)
* develop: (22 commits)
Update docs
Added CKEditor and GitHub Writer to available integrations.
chore(deps): update all patch dependencies
build(deps): fix broken pnpm-lock.yaml file
Mermaid version 10.2.0
Mermaid Version 10.2.0-rc.4
Label background fix
Test commit
Fix for regression error in sequenceDiagrams
Fix visibility issue for fields
fix parsing issue with class diagrams
fix: Use unicode arrows in quadrant chart axis
fix: Use unicode arrows in quadrant chart axis
fix lint command
Bump version
Back to JS with jsdoc types
Add unsupported text
Reduce changes in test
Fix deps
Fix lockfile
...
Looks like a bad merge conflict resolution broke this file,
and for some reason, the `packages/mermaid/src/vitepress` bit got
removed when releasing v10.2.0-rc.4.
Fixes: bd1343648e
Fixes: 9c12c42a26
* develop: (66 commits)
Update docs
Update docs
Improve the wording of security level values
Added quadrantChart to the side bar
Added e2e test cases with some fixes
Added documentation for the quadrantChart
Restructured the build function and addressed more review comment
Fixed some parser issue and added test cases for the parser
Fixed review comment
Update docs
Converted files to typescript and added proper types
Fix blog linting
Debug fetch-contributors
Fix lockfile
Revert "Replace esno & ts-node with tsx"
[draft] Added support for quadrant chart
Fix lockfile
Fix build
Update pnpm-lock
Replace esno & ts-node with tsx
...
Merge conflicts:
- pnpm-lock.yaml
* develop: (66 commits)
Update docs
Update docs
Improve the wording of security level values
Added quadrantChart to the side bar
Added e2e test cases with some fixes
Added documentation for the quadrantChart
Restructured the build function and addressed more review comment
Fixed some parser issue and added test cases for the parser
Fixed review comment
Update docs
Converted files to typescript and added proper types
Fix blog linting
Debug fetch-contributors
Fix lockfile
Revert "Replace esno & ts-node with tsx"
[draft] Added support for quadrant chart
Fix lockfile
Fix build
Update pnpm-lock
Replace esno & ts-node with tsx
...
- The current wording can be misinterpreted because, for some people
'tags' might not be associated with HTML tags.
- Improve the wording to make it clear that HTML tags are intended.
This adds the projects `mermaid-isomorphic`, `rehype-mermaidjs`, and
`gatsby-remark-mermaid` to the integrations page.
This also removes `remark-mermaid`. This project is outdated and
unmaintained.
The classDiagramGrammer.spec.ts unit test had some bad filepath
manipulation that fails on UNIX platforms.
Instead, we can use the recommended method from the Node.JS
documentation, see https://nodejs.org/api/esm.html#importmetaurl.
Fixes: 221640aa25
* develop: (237 commits)
submit built docs
update Font Awesome Version
Clarify FontAwesome support
Update version
Fix classParser
Check for conflict when linting jison
Update class grammar test
fix Class diagram grammar
Skip sourcemap
Bump version
Update deps
Fix unit tests
Update vite
Fix applitools cypress
Update packages/mermaid/package.json
chore(deps): update dependency typescript to v5
fix typedoc
fix(deps): update all minor dependencies
chore(deps): update pnpm to v8
chore(deps): update fregante/setup-git-user action to v2
...
* develop: (33 commits)
Update version
Fix classParser
Check for conflict when linting jison
Update class grammar test
fix Class diagram grammar
Skip sourcemap
Bump version
Update deps
Fix unit tests
Update vite
Fix applitools cypress
Update packages/mermaid/package.json
chore(deps): update dependency typescript to v5
fix typedoc
fix(deps): update all minor dependencies
chore(deps): update pnpm to v8
chore(deps): update fregante/setup-git-user action to v2
fix(deps): update all minor dependencies
chore(deps): update dependency start-server-and-test to v2
chore(deps): update dependency rimraf to v5
...
* 'renovate/all-minor' of https://github.com/mermaid-js/mermaid:
fix(deps): update all minor dependencies
chore(deps): update pnpm to v8
chore(deps): update fregante/setup-git-user action to v2
Test that `src/diagrams/*/styles.ts` module returns a valid
CSS stylesheet that can be parsed via [stylis][1] and then
becomes a valid CSS that [csstree-validator][2] validates.
We test this for every diagram and for every theme, because
many of the invalid CSS bugs are caused by missing theme vars.
There are some CSS errors that I couldn't easily fix, so I've written
the tests to ignore the following CSS errors:
- 'Unknown property `rx`' (Valid in SVG2 draft and in some browsers)
- 'Unknown property `ry`' (Valid in SVG2 draft and in some browsers)
- 'Unknown property `dy`'
- This doesn't seem to be valid CSS in any SVG version, but maybe
some browsers support it 🤷 I feel like we should probably change
this though.
[1]: https://github.com/thysultan/stylis
[2]: https://github.com/csstree/validator
The `scaleLabelColor` variable in `theme-forest` and `theme-neutral`
was set to `"calculated"`, as it defaults to `this.labelTextColor`
**before** `this.labelTextColor` was set.
Moving the `this.labelTextColor` assignments before `scaleLabelColor`
is calculated fixes this.
Fixes mindmap and timeline invalid CSS in theme forest and neutral.
Define `excludeBkgColor` for `theme-dark` to fix invalid CSS
for gantt diagrams.
All the other themes defined this to '#eeeeee', but I thought that
was a bit too bright in a dark theme, so instead I set it to
`darken(this.sectionBkgColor, 10);`.
`border2` is a theme variable used by the CSS for flowcharts and
user-journey.
I've defined this to default to `tertiaryBorderColor` in theme-base,
as other themes tend to set `border2` to the same value as
`clusterBorder`, which in theme-base is `tertiaryBorderColor`.
Define `arrowheadColor` as `invert(this.background)` in
`theme-base.js`, as it's currently `undefined`, which causes CSS
issues when using `theme-base`.
I've picked `invert(this.background)` so that it matches
the default value of `lineColor`.
Currently, `requirementBorderSize` defaults to `primaryBorderColor`,
which is a color, not a valid SVG `stroke-width`.
Instead, I've made it default to `1`.
Fix an invalid value for the CSS `fill-opacity` value.
Percentage values for `fill-opacity` are only supported in the SVG 2.0
draft, so according to [MDN][1]:
> it is not widely supported yet, […] as a consequence, it is best
> practices [sic] to set opacity with a value in the range `[0-1]`.
[1]: https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/fill-opacity
The current `personBorder`/`personBkg` theme variables for C4 diagrams
are set to the string `'calculated'`.
However, despite being `'calculated'`, they never seem to change to
anything else, and so become invalid CSS variables.
I've instead changed these to just default to base theme vars,
as that's what they do in [`these-base.js`][1].
[1]: 727bf30824/packages/mermaid/src/themes/theme-base.js (L106-L107)
In #3938, it appears that the marker sizes for pointEnd was
unintentionally changed. This reverts the change in marker size.
It is also possible that the intention was to change the viewBox size
for both start and end, but I doubt this since it makes the arrows
significantly smaller than other markers.
* develop: (81 commits)
revert pnpm changes
doc update
auto generated from pnpm run
auto generated from pnpm run
linting
added example of Bar chart
Update docs
Adding rendering tests and unit tests
Syntax for markdown strings is a single backtick.
updated labels in the chart
Update docs
updated example data smaller
Bar chart
fix: Remove comment line completely
fix: trimStart to text
test: add space before init
fix uncaughexception in tests
fix(#4256): Keep error diagram on screen
fix(#4137): Cleanup comments before parsing
Update docs
...
Remove the `use-inline-specifiers-lockfile-format=true` pnpm option
from our `.npmrc` file.
This was added in
[PNPM version v7.7.0](https://github.com/pnpm/pnpm/releases/tag/v7.7.0)
and should make our `pnpm-lock.yaml` file much nicer,
but unfortunately, renovate doesn't seem to support it (unsure why?).
This means that whenever we do a `pnpm install` locally, the lock-file
gets changed, and whenever renovate makes a PR, it changes the
lock-file back. This causes a lot of unnecassary merge conflicts.
The `node16` module resolution requires imports to use the `.js` file
extension in type definitions.
`@rollup/plugin-typescript` is needed to make this work with the Vite
setup used by Mermaid.
The module option for Mermaid internally is set to `nodenext`. This is
needed to support `.json` imports. Note that setting `module` to
`node16` or `nodenext` implies a matching `moduleResolution` value.
The gantt diagram that were supposed to test whether
`todayMarker off` works wasn't working properly, because
`todayMarker on` wasn't working (i.e. the test never failed).
I've fixed this issue, and added a test that checks whether
`todayMarker on` works.
Fixes: https://github.com/mermaid-js/mermaid/issues/4198
* develop:
fix(deps): update all non-major dependencies
chore(deps): update all non-major dependencies
Update Diagram.ts
Update Diagram.ts
feat: added internal label
feat: improve documentation
make clearer
fix: invalid url and generate docs
Update integrations.md to include Mermaid Flow
feat: expose the diagram api
fixup! fixup! Move pie outerStrokeWidth to theme variables, update docs
fixup! Move pie outerStrokeWidth to theme variables, update docs
Move pie outerStrokeWidth to theme variables, update docs
fixup! fixup! feat(pie): adding outer border, text position options
fixup! feat(pie): adding outer border, text position options
Update packages/mermaid/src/diagrams/pie/pieRenderer.js
feat(pie): adding outer border, text position options
* master:
v10.0.2
fix: dayjs import extension
Setting version to 10.0.1
#4168 Adding the correct offset for the edges
Updated import of cytoscape for consistent behavior
Use cytoscape esm
Revert "chore: Defer elk loading"
Revert "Split cytoscape"
fix: Class with members and styles
Add a quick test that ensures `ganttDb` correctly adds `1d` (1 day),
even on days with 25 hours.
This test only runs if the test PC has the TZ='America/Los_Angeles'
set (California has daylight savings).
I've added a test to the GitHub Actions `test.yml` action too for this.
It should only add about 5 seconds to each test, so it isn't too bad.
Replace Mermaid's dependency on `moment` with `dayjs`.
[Moment is now in maintenance mode][1], and they don't recommend
using it.
[Dayjs][2] has almost exactly the same API as moment, and is still
curently being maintained. Unlike moment, dayjs objects are immutable,
which makes our life much easier, but we need to do
`a = a.add(1, "day")` instead of just `a.add(1, "day")`.
We can't use `dayjs.duration`, because unlike `moment.duration`,
[dayjs durations always degrade to ms][3].
This causes issues with daylight savings, since it assumes that each
day is 24 hours, when some days have 23/25 hours with daylight savings.
(it also assumes that each month is 30 days).
However, `dayjs.add(1, "d");` correctly adds 1 days, even when that
day is only 23 hours long, so we can use that instead.
[1]: https://momentjs.com/docs/#/-project-status/
[2]: https://day.js.org/
[3]: https://day.js.org/docs/en/durations/durations
Co-authored-by: Alois Klink <alois@aloisklink.com>
// this file is automatically generated by `pnpm run --filter mermaid types:build-config`
'packages/mermaid/src/config.type.ts',
],
rules:{
curly:'error',
'no-console':'error',
@@ -123,6 +127,14 @@ module.exports = {
files:['*.{ts,tsx}'],
plugins:['tsdoc'],
rules:{
'no-restricted-syntax':[
'error',
{
selector:'TSEnumDeclaration',
message:
'Prefer using TypeScript union types over TypeScript enum, since TypeScript enums have a bunch of issues, see https://dev.to/dvddpl/whats-the-problem-with-typescript-enums-2okj',
@@ -13,6 +13,6 @@ Describe the way your implementation works or what design decisions you made if
Make sure you
- [ ] :book: have read the [contribution guidelines](https://github.com/mermaid-js/mermaid/blob/develop/CONTRIBUTING.md)
- [ ] :computer: have added unit/e2e tests (if appropriate)
- [ ] :notebook: have added documentation (if appropriate)
- [ ] :computer: have added necessary unit/e2e tests.
- [ ] :notebook: have added documentation. Make sure [`MERMAID_RELEASE_VERSION`](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/docs/community/development.md#3-update-documentation) is used for all new features.
Please read in detail about how to contribute documentation and code on the [Mermaid documentation site.](https://mermaid-js.github.io/mermaid/#/development)
---
Here are a few things to know to get you started on the right path.
Below link will help you making a copy of the repository in your local system.
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
```
## Committing code
### Docker
We make all changes via pull requests. As we have many pull requests from developers new to mermaid, the current approach is to have _knsv, Knut Sveidqvist_ as a main reviewer of changes and merging pull requests. More precisely like this:
- Large changes reviewed by knsv or other developer asked to review by knsv
- Smaller low-risk changes like dependencies, documentation, etc. can be merged by active collaborators
- Documentation (updates to the `package/mermaid/src/docs` folder is also allowed via direct commits)
To commit code, create a branch, let it start with the type like feature or bug followed by the issue number for reference and some describing text.
One example:
`feature/945_state_diagrams`
Another:
`bug/123_nasty_bug_branch`
## Committing documentation
Less strict here, it is OK to commit directly in the `develop` branch if you are a collaborator.
The documentation is written in **Markdown**. 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).
### Documentation source files are in [`/packages/mermaid/src/docs`](packages/mermaid/src/docs)
The source files for the project documentation are located in the [`/packages/mermaid/src/docs`](packages/mermaid/src/docs) directory. This is where you should make changes.
The files under `/packages/mermaid/src/docs` are processed to generate the published documentation, and the resulting files are put into the `/docs` directory.
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"]
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
```
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.
## Testing
````
```note
Note content
```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
```
```tip
Tip content
## Branch name format:
```text
[feature | bug | chore | docs]/[issue number]_[short description using dashes ('-') or underscores ('_') instead of spaces]
Documentation is necessary for all non bugfix/refactoring changes.
Only make changes to files are in [`/packages/mermaid/src/docs`](packages/mermaid/src/docs)
**_DO NOT CHANGE FILES IN `/docs`_**
### The official documentation site
**[The mermaid documentation site](https://mermaid-js.github.io/mermaid/) is powered by [Vitepress](https://vitepress.vuejs.org/), a simple documentation site generator.**
If you want to preview the whole documentation site on your machine:
```sh
cd packages/mermaid
pnpm i
pnpm docs:dev
```
You can now build and serve the documentation site:
```sh
pnpm docs:serve
```
## Branching
Going forward we will use a git flow inspired approach to branching. So development is done in develop, to do the development in the develop.
Once development is done we branch a release branch from develop for testing.
Once the release happens we merge the release branch to master and kill the release branch.
This means... **branch off your pull request from develop**
## Content of a pull request
A new feature has been born. Great! But without the steps below it might just ... fade away ...
### **Add unit tests for the parsing part**
This is important so that, if someone else does a change to the grammar that does not know about this great feature, gets notified early on when that change breaks the parser. Another important aspect is that without proper parsing tests refactoring is pretty much impossible.
### **Add e2e tests**
This tests the rendering and visual appearance of the diagram. 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 run dev` to start the dev server, after that start cypress by running `pnpm exec cypress open` in the mermaid folder.
The rendering tests are very straightforward to create. There is a function imgSnapshotTest. This function takes a diagram in text form, the mermaid options and 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 for review it if it differs.
This is what a rendering test looks like:
```javascript
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');
});
```
### **Add documentation for it**
Finally, if it is not in the documentation, no one will know about it and then **no one will use it**. Wouldn't that be sad? With all the effort that was put into the feature?
The source files for documentation are in `/packages/mermaid/src/docs` and are written in markdown. Just pick the right section and start typing. See the [Committing Documentation](#committing-documentation) section for more about how the documentation is generated.
#### Adding to or changing the documentation organization
If you want to add a new section or change the organization (structure), then you need to make sure to **change the side navigation** in `mermaid/src/docs/.vitepress/config.js`.
When changes are committed and then released, they become part of the `master` branch and become part of the published documentation on https://mermaid-js.github.io/mermaid/
## 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)
[](https://github.com/mermaid-js/mermaid/actions/workflows/build.yml)
### User Journey diagram [<a href="https://mermaid-js.github.io/mermaid/#/user-journey">docs</a> - <a href="https://mermaid.live/edit#pako:eNplkMFuwjAQRH9l5TMiTVIC-FqqnjhxzWWJN4khsSN7XRSh_HsdKBVt97R6Mzsj-yoqq0hIAXCywRkaSwNxWHNHsB_hYt1ZmwYUfiueKtbWwIcFtjf5zgH2eCZgQgkrCXt64GgMg2fUzkvIn5Xd_V5COtMFvCH_62ht_5yk7MU8sn61HDTfxD8VYiF6cj1qFd94nWkpuKWYKWRcFdUYOi5FaaZoDYNCpnel2Toha-w8LQQGtofRVEKyC_Qw7TQ2DvsfV2dRUTy6Ch6H-UMb7TlGVtbUupl5cF3ELfPgZZLM8rLR3IbjsrJ94rVq0XH7uS2SIis2mOVUrHNc5bmqjul2U2evaa3WL2mGYpqmL2BGiho">live editor</a>]
```
@@ -334,7 +386,7 @@ Update version number in `package.json`.
npm publish
```
The above command generates files into the `dist` folder and publishes them to npmjs.org.
The above command generates files into the `dist` folder and publishes them to <https://www.npmjs.com>.
## Related projects
@@ -350,7 +402,7 @@ Detailed information about how to contribute can be found in the [contribution g
## Security and safe diagrams
For public sites, it can be precarious to retrieve text from users on the internet, storing that content for presentation in a browser at a later stage. The reason is that the user content can contain embedded malicious scripts that will run when the data is presented. For Mermaid this is a risk, specially as mermaid diagrams contain many characters that are used in html which makes the standard sanitation unusable as it also breaks the diagrams. We still make an effort to sanitise the incoming code and keep refining the process but it is hard to guarantee that there are no loop holes.
For public sites, it can be precarious to retrieve text from users on the internet, storing that content for presentation in a browser at a later stage. The reason is that the user content can contain embedded malicious scripts that will run when the data is presented. For Mermaid this is a risk, specially as mermaid diagrams contain many characters that are used in html which makes the standard sanitation unusable as it also breaks the diagrams. We still make an effort to sanitize the incoming code and keep refining the process but it is hard to guarantee that there are no loop holes.
As an extra level of security for sites with external users we are happy to introduce a new security level in which the diagram is rendered in a sandboxed iframe preventing javascript in the code from being executed. This is a great step forward for better security.
@@ -358,7 +410,7 @@ _Unfortunately you can not have a cake and eat it at the same time which in this
## Reporting vulnerabilities
To report a vulnerability, please e-mail security@mermaid.live with a description of the issue, the steps you took to create the issue, affected versions, and if known, mitigations for the issue.
To report a vulnerability, please e-mail <security@mermaid.live> with a description of the issue, the steps you took to create the issue, affected versions, and if known, mitigations for the issue.
[](https://github.com/mermaid-js/mermaid/actions/workflows/build.yml)
it('New line in node and formatted edge label',()=>{
imgSnapshotTest(
`%%{init: {"flowchart": {"htmlLabels": true}} }%%
flowchart-elk LR
b("\`The dog in **the** hog.(1)
NL\`") --"\`1o **bold**\`"--> c
`,
{flowchart:{titleTopMargin:0}}
);
});
it('Wrapping long text with a new line',()=>{
imgSnapshotTest(
`%%{init: {"flowchart": {"htmlLabels": true}} }%%
flowchart-elk LR
b(\`The dog in **the** hog.(1).. a a a a *very long text* about it
Word!
Another line with many, many words. Another line with many, many words. Another line with many, many words. Another line with many, many words. Another line with many, many words. Another line with many, many words. Another line with many, many words. Another line with many, many words. \`) --> c
`,
{flowchart:{titleTopMargin:0}}
);
});
it('Sub graphs and markdown strings',()=>{
imgSnapshotTest(
`%%{init: {"flowchart": {"htmlLabels": true}} }%%
flowchart-elk LR
subgraph "One"
a("\`The **cat**
in the hat\`") -- "1o" --> b{{"\`The **dog** in the hog\`"}}
end
subgraph "\`**Two**\`"
c("\`The **cat**
in the hat\`") -- "\`1o **ipa**\`" --> d("The dog in the hog")
b("\`The dog in **the** hog.(1).. a a a a *very long text* about it
Word!
Another line with many, many words. Another line with many, many words. Another line with many, many words. Another line with many, many words. Another line with many, many words. Another line with many, many words. Another line with many, many words. Another line with many, many words. \`") --> c
it('New line in node and formatted edge label',()=>{
imgSnapshotTest(
`%%{init: {"flowchart": {"htmlLabels": true}} }%%
flowchart LR
b("\`The dog in **the** hog.(1)
NL\`") --"\`1o **bold**\`"--> c
`,
{flowchart:{titleTopMargin:0}}
);
});
it('Wrapping long text with a new line',()=>{
imgSnapshotTest(
`%%{init: {"flowchart": {"htmlLabels": true}} }%%
flowchart LR
b("\`The dog in **the** hog.(1).. a a a a *very long text* about it
Word!
Another line with many, many words. Another line with many, many words. Another line with many, many words. Another line with many, many words. Another line with many, many words. Another line with many, many words. Another line with many, many words. Another line with many, many words. \`") --> c
`,
{flowchart:{titleTopMargin:0}}
);
});
it('Sub graphs and markdown strings',()=>{
imgSnapshotTest(
`%%{init: {"flowchart": {"htmlLabels": true}} }%%
flowchart LR
subgraph "One"
a("\`The **cat**
in the hat\`") -- "1o" --> b{{"\`The **dog** in the hog\`"}}
end
subgraph "\`**Two**\`"
c("\`The **cat**
in the hat\`") -- "\`1o **ipa**\`" --> d("The dog in the hog")
b("\`The dog in **the** hog.(1).. a a a a *very long text* about it
Word!
Another line with many, many words. Another line with many, many words. Another line with many, many words. Another line with many, many words. Another line with many, many words. Another line with many, many words. Another line with many, many words. Another line with many, many words. \`") --> c
b("`The dog in **the** hog.(1).. a a a a *very long text* about it
Word!
Another line with many, many words. Another line with many, many words. Another line with many, many words. Another line with many, many words. Another line with many, many words. Another line with many, many words. Another line with many, many words. Another line with many, many words.`") --apa--> c
> ## Please edit the corresponding file in [/packages/mermaid/src/docs/community/development.md](../../packages/mermaid/src/docs/community/development.md).
# Development and Contribution 🙌
# Contributing to Mermaid
## Contents
- [Technical Requirements and Setup](#technical-requirements-and-setup)
- [Questions or Suggestions?](#questions-or-suggestions)
- [Last Words](#last-words)
---
So you want to help? That's great!
@@ -12,72 +22,167 @@ So you want to help? That's great!
Here are a few things to get you started on the right path.
**The Docs Structure is dictated by [.vitepress/config.ts](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/docs/.vitepress/config.ts)**.
## Technical Requirements and Setup
**Note: Commits and Pull Requests should be directed to the develop branch.**
### Technical Requirements
## Branching
These are the tools we use for working with the code and documentation.
Mermaid uses a [Git Flow](https://guides.github.com/introduction/flow/)–inspired approach to branching. So development is done in the `develop` branch.
- [volta](https://volta.sh/) to manage nodeversions.
- [npx](https://docs.npmjs.com/cli/v8/commands/npx) the packaged executor in npm. This is needed [to install pnpm.](#2-install-pnpm)
Once development is done we branch a `release` branch from `develop` for testing.
Follow [the setup steps below](#setup) to install them and verify they are working
Once the release happens we merge the `release` branch with `master` and kill the `release` branch.
### Setup
This means that **you should branch off your pull request from develop** and direct all Pull Requests to it.
Follow these steps to set up the environment you need to work on code and/or documentation.
#### 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:
```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
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:
```bash
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.)
### 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
We make all changes via Pull Requests. As we have many Pull Requests from developers new to mermaid, we have putin place a process, wherein _knsv, Knut Sveidqvist_ is the primary reviewer of changes and merging pull requests. The process is as follows:
The basic steps for contributing code are:
- Large changes reviewed by knsv or other developer asked to review by knsv
- Smaller, low-risk changes like dependencies, documentation, etc. can be merged by active collaborators
- Documentation (we encourage updates to the `/packages/mermaid/src/docs` folder; you can submit them via direct commits)
```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]
```
When you commit code, create a branch with the following naming convention:
```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]
```
Start with the type, such as **feature** or **bug**, followed by the issue number for reference, and a text that describes the issue.
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.
**One example:**
### 1. Checkout a git branch
`feature/945_state_diagrams`
Mermaid uses a [Git Flow](https://guides.github.com/introduction/flow/)–inspired approach to branching.
**Another example:**
Development is done in the `develop` branch.
`bug/123_nasty_bug_branch`
Once development is done we create a `release/vX.X.X` branch from `develop` for testing.
## Contributing to Documentation
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.
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?
**All new work should be based on the `develop` branch.**
The docs are located in the `src/docs` folder and are written in Markdown. Just pick the right section and start typing. If you want to propose changes to the structure of the documentation, such as adding a new section or a new file you do that via **[.vitepress/config.ts](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/docs/.vitepress/config.ts)**.
**When you are ready to do work, always, ALWAYS:**
> **All the documents displayed in the GitHub.io page are listed in [.vitepress/config.ts](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/docs/.vitepress/config.ts)**.
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.
The contents of <https://mermaid-js.github.io/mermaid/> are based on the docs from the `master` branch. Updates committed to the `master` branch are reflected in the [Mermaid Docs](https://mermaid-js.github.io/mermaid/) once released.
We use the follow naming convention for branches:
## How to Contribute to Documentation
```text
[feature | bug | chore | docs]/[issue number]_[short description using dashes ('-') or underscores ('_') instead of spaces]
```
We are a little less strict here, it is OK to commit directly in the `develop` branch if you are a collaborator.
- 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)
The documentation is located in the `src/docs` directory and organized according to relevant subfolder.
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.
The `docs` folder will be automatically generated when committing to `src/docs` and should not be edited manually.
**Ex: A new feature described in issue 2945 that adds a new arrow type called 'florbs' to state diagrams**
We encourage contributions to the documentation at [mermaid-js/mermaid/src/docs](https://github.com/mermaid-js/mermaid/tree/develop/packages/mermaid/src/docs). We publish documentation using GitHub Pages with [Docsify](https://www.youtube.com/watch?v=TV88lp7egMw&t=3s)
`feature/2945_state-diagram-new-arrow-florbs`
### Add Unit Tests for Parsing
**Ex: A bug described in issue 1123 that causes random ugly red text in multiple diagram types**
`bug/1123_fix_random_ugly_red_text`
This is important so that, if someone that does not know about this great feature suggests a change to the grammar, they get notified early on when that change breaks the parser. Another important aspect is that, without proper parsing, tests refactoring is pretty much impossible.
### 2. Write Tests
### Add E2E 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).
This tests 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!
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 run dev` to start the dev server
2. Start **Cypress** by running `pnpm exec cypressopen` in the **mermaid** folder.
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.
**_\[TODO - running the tests against what is expected in development. ]_**
After logging in at [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).
**_\[TODO - how to generate new screenshots]_**
....
### How to Contribute a Suggestion
### 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.
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"]
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:
1. Find the Markdown file (.md) to edit in the [packages/mermaid/src/docs](https://github.com/mermaid-js/mermaid/tree/develop/packages/mermaid/src/docs) directory in the `develop`branch.
2. Create a fork of the develop branch.
_\[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 fork and push it to GitHub.
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).
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.Create a Pull Request of your newly forked branch by clicking the green **Create Pull Request** button.
6. Visit the Actions tab in Github, `https://github.com/<YourUsername>/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.
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
## Last Words
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
