Add a config validator and organise global configs

[sidharthv96]

Add a config validator to make sure config is passed in right place & format. (It should also handle transforming legacy config). This would make the internal code a lot cleaner.

All global configs should be grouped together as mentioned in #3337
Related #1172

[sidharthv96]

Should standardize config naming convention.

[sidharthv96]

Key points

• Should not break existing configs
• Any new config should only be added in the new format
• Ability to deprecate configs with warning
• Should convert config to a standard format for all internal use. This should remove edge case checking in many places.
• Directives should be handled

flowchart
Old["{Old Config+New Config}"] -->Validate 
Validate --> Transform 
Transform --> InternalConfig

Loading

[knsv]

Let us not forget about the decoupled diagrams. With a decoupled diagram I mean a diagram built outside of Mermaid (core) that is registering itself as a diagram that Mermaid can render. These diagrams will likly have additional configuration parameters etc.

[weedySeaDragon]

@knsv and @sidharthv96 I've posted my thoughts on Themes and configuration in a discussion.
#3495

I think that figuring out how Themes will work & be implemented will answer many of the questions for how Configurations should work & be implemented.

[jgreywolf]

@sidharthv96 Is this issue considered resolved with the merge of the two 10.0 PR listed above?

[sidharthv96]

I don't think so.
We didn't do any major changes to configs in v10.

[aloisklink]

I have a pending PR that will change the MermaidConfig to be defined in a single-file¹ using JSONSchema: #4112 (it's got a bunch of merge conflicts that I don't want to fix until Mermaid v10.2.0 gets merged to main, then the main branch gets merged back to develop²)

We would then have a single file where:

• The default values are located¹
• The types of the values are located (and whether they're optional/required)
  • That PR makes the TypeScript value of every value optional, to match our existing types and to avoid causing any breaking changes.
• The documentation for values is located

Once that gets merged, we can make the following breaking changes:

• Use a json-schema-validator like ajv to automatically warn/error about invalid config entries (this is what eslint/webpack uses for validating their configs)
• Make every config option that is required required in TypeScript, so that we can remove edge-checking, since TypeScript will know these fields will always exist.

Footnotes

1. Except for non-JSON default values, i.e. functions like FontCalculator. ↩ ↩²

2. We might want to reconsider our practice of make a release branch off develop, merging it to main, then merging main back to develop. It's a bit unusual, and it seems to cause a bunch of Git conflicts. ↩

[sidharthv96]

@aloisklink, now that #4112 is merged, should we create separate issues for the 2 breaking changes mentioned?

[aloisklink]

@aloisklink, now that #4112 is merged, should we create separate issues for the 2 breaking changes mentioned?

I think, after talking to @Yokozuna59, we can do be both of these things, without having any breaking changes.

• Make every config option that is required required in TypeScript, so that we can remove edge-checking, since TypeScript will know these fields will always exist.

I think, after talking with @Yokozuna59 (see https://github.com/orgs/mermaid-js/discussions/4710#discussioncomment-6709156), it probably makes more sense to make everything in the MermaidConfig JSON Schema and TypeScript types optional. If we then make every default value in the MermaidConfig not undefined (but maybe null), then we can make functions like getConfig() return RequiredDeep<MermaidConfig> and we will know that none of the values are undefined.

After we make that change, adding ajv to print warnings will be even easier!

[Yokozuna59]

Should standardize config naming convention.

And rename colour to color (since most of them are already color).

---

And I think we should remove functions from the defaultConfig, they're more like helper functions to be used in renderer rather than separate attribute. We could create those functions in DB instead.