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
