-
Notifications
You must be signed in to change notification settings - Fork 182
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
Add option to preserve casing when generating links #301
Comments
Apologies for delay on this been busy on other stuff. Have implemented, just tweaked the option name slightly to Point noted about the options - what is missing a contributing guide that will get around to at some point. |
Thanks @tgreyuk !!! |
As a cookie crumb trail for anyone trying to use Here's the syntax: So your package.json might look something like this: "docs" : "typedoc --options typedoc-markdown.js && docusaurus write-heading-ids ./typedocs/* --maintain-case true && docusaurus start" |
Request:
Add a new option
preseveDeclarationCasing
that, if set to true, will not convert declarations to lowercase.Rationale:
typedoc-plugin-markdown automatically sets all id's and links to lowercase. This is in accordance with the spec for id tags, and in general how markdown works, but in so doing the original capitalization of declarations are lost. This is often undesirable when the markdown conversion is an interim step to converting to html (for instance, site generators such as Docusaurus and JSDocs are oriented around markdown as input but ultimately render their output as HTML where originally cased anchors are desirable).
Example,
ListenerParam
as output by Typedoc into html:Output as
listenerparam
by markdown plugin:Notes:
This appears to be a trivial change to this one line:
https://github.com/tgreyuk/typedoc-plugin-markdown/blob/master/packages/typedoc-plugin-markdown/src/theme.ts#L162
I did attempt a PR but I found that in order to create a new option for the plugin it was also necessary to make that same change in Typedoc itself because it validates and strongly types all options. That increased the burden of effort for someone who isn't in the groove of working with this project.
This seems problematic if one desires a healthy plugin ecosystem. Perhaps I'm missing a nuance, but if not then I would like to suggest that providing an explicit
any
namespace in config for plugins would lower barriers to plugin development and prevent possible collisions, e.g.The text was updated successfully, but these errors were encountered: