This attempts to maintain the current behaviour.
Previously, because HREF contained a space and called
a state, the href token was able to be placed in the
beginning of node ids (because it wouldn't conflict
without the space). We require the space to keep that
behaviour.
Originally, I thought this was necessary to prevent parsing
the token as part of an edge. I forgot that the token will always
be separated from the link/edge by the node id. Added an unit test
for an edge case to be certain.
Previously, you were allowed to define a class called 'default'
but were not allowed to use it because the classStatement grammar
expected an alphanum, which did not include the word DEFAULT
Similar to what was done in the class diagram parser,
this will allow string tokens to appear in any state.
This is especially helpful, because it will simplify the
code and any future refactoring
This was never really used and had many things wrong with it.
I believe that if a hex was provided in the diagram specification,
the alphanum grammar would break it up into a BRKT and NUM token
and use the first line with the addVertex() function.
Second, the styleLink grammar provides the exact same functionality
with the linkStyle keyword.
Third, updateLink() expects an array of nums, not a hex digit.
Fourth, no documentation is provided on this grammar statement existing.
Fifth, the unit test does not work in version 10.2.4
What this allows is for idStrings that are separated by
dashes or underscores to be considered one whole string
rather than a bunch of tokens mixed together.
This is necessary for examples such as a-node-graph[text].
Now, the last part of the idString 'graph' will be read as
part of the NODE_STRING token rather than attempting to add
a GRAPH token to the idString.
* 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
Our current method of adding a entry using `+=` is not safe in YAML,
since it's valid to make a YAML object entirely in JSON,
see https://github.com/mermaid-js/mermaid/pull/4640#discussion_r1265133463
We're already using `js-yaml` elsewhere in this file, so we may as well
use it for parsing/stringifying.
Reported-by: Remco Haszing <remcohaszing@gmail.com>
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`.
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.
Reda Al Sulais