-
Notifications
You must be signed in to change notification settings - Fork 592
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[api-documenter] ExperimentalYamlDocumenter suggestions #1831
Comments
In the current design of TSDoc, block tags cannot have parameters. This is a general issue that affects many other tags such as
We recently added a This work started in PR #1628 but stalled because the original reporter found a workaround that unblocked them. It's not a lot of work to finish it, though. The
The rest of your suggests all seem like good ideas to me. 👍👍 The idea behind You could start by proposing improvements to the |
My team has moved to a different team and no longer maintains the documentation project. We have set it on auto-update that runs every morning and so far all good. The implementation of the As far who is going to own the Fabric docs on |
Is this a feature or a bug?
While I know that
ExperimentalYamlDocumenter
is an experimental feature, I have some suggestions and concerns about its design:@docCategory
(or whatever you name it via"categoryInlineTag"
) doesn't make much sense as an inline tag. A block tag seems like a better fit.@docCategory
-like tag in the standard tsdoc set of tags and it's not obvious how to register it or configure tsdoc when running theapi-documenter
CLI.uid
/DeclarationReference
or some other mechanism, notname
. I might want to have two nested categories with the same name."noDocumentationTag": "ignore"
and/** @ignore */ ...
metadata
or a custom field in the TOC item itself rather than a side-table in the config likenonEmptyCategoryNodeNames
. Its easier to write a custom config when the effects that apply to a TOC item are local to the TOC item. For example:toc.yml
files they are already working with and it would be more convenient to author using a single syntax vs. jumping back and forth between JSON and YAML syntax rules.The text was updated successfully, but these errors were encountered: