You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Given that everything else in DocFX seems to be defined using YAML, e.g. toc.yml, xrefmap.yml, filter.yml, YAML-metadata in markdown files, etc, it is somewhat surprising to find docfx.json as the config entry point for DocFX.
Is there a reason for this? The only advantage I could come up with would be if the DocFX metadata was used directly in JavaScript or TypeScript as a data dictionary, but this doesn't seem to be a feature. With the complexity of possible configurations growing, and the absence of a formal JSON-schema specification or API for automatically manipulating the config file, the overwhelming majority of existing projects seem to be simply editing this file by hand.
If manual editing is the foreseeable future, then I would argue that YAML would be a much better suited format, with a much nicer human-readable syntax, support for multi-line strings (e.g. for writing _appFooter), etc.
Describe the solution you'd like
Support docfx.yml in addition to docfx.json. Given that YamlDotNet is already a project dependency, and that YAML is a superset of JSON, it should be possible to have a single set of domain classes that can be serialized into/out of either JSON or YAML. If the config file is described in a JSON-schema, as proposed in #8968 and #7736, the exact same schema could be used to support auto-completion of both YAML and JSON.
Describe alternatives you've considered
The only other alternative would be to write a JSON-schema for docfx.json and then use a dedicated pre-processing tool to convert docfx.yml to docfx.json at build time. The advantage of this alternative is it doesn't require any changes to DocFX and could be done using an externally developed tool. The disadvantage is having a forked implementation of a critical entry-point component is very risky for any long-term maintenance, especially in the lack of a formal JSON-schema to drive and validate the automations.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Given that everything else in DocFX seems to be defined using YAML, e.g.
toc.yml
,xrefmap.yml
,filter.yml
, YAML-metadata in markdown files, etc, it is somewhat surprising to finddocfx.json
as the config entry point for DocFX.Is there a reason for this? The only advantage I could come up with would be if the DocFX metadata was used directly in JavaScript or TypeScript as a data dictionary, but this doesn't seem to be a feature. With the complexity of possible configurations growing, and the absence of a formal JSON-schema specification or API for automatically manipulating the config file, the overwhelming majority of existing projects seem to be simply editing this file by hand.
If manual editing is the foreseeable future, then I would argue that YAML would be a much better suited format, with a much nicer human-readable syntax, support for multi-line strings (e.g. for writing
_appFooter
), etc.Describe the solution you'd like
Support
docfx.yml
in addition todocfx.json
. Given thatYamlDotNet
is already a project dependency, and that YAML is a superset of JSON, it should be possible to have a single set of domain classes that can be serialized into/out of either JSON or YAML. If the config file is described in a JSON-schema, as proposed in #8968 and #7736, the exact same schema could be used to support auto-completion of both YAML and JSON.Describe alternatives you've considered
The only other alternative would be to write a JSON-schema for
docfx.json
and then use a dedicated pre-processing tool to convertdocfx.yml
todocfx.json
at build time. The advantage of this alternative is it doesn't require any changes to DocFX and could be done using an externally developed tool. The disadvantage is having a forked implementation of a critical entry-point component is very risky for any long-term maintenance, especially in the lack of a formal JSON-schema to drive and validate the automations.The text was updated successfully, but these errors were encountered: