Suggestion: Custom footer string

[nicfv]

Search Terms

custom, footer, string, hide, generator

Problem

By using the --hideGenerator option, the message "created by TypeDoc" is removed, but the footer is still there. It might be nice to include an option to customize what is written in the footer instead.

Suggested Solution

--footer "<span class="...">should support html</span>"

[Gerrit0]

Sure, seems like an easy customization to allow

[Aryakoste]

Hello @Gerrit0. I would like to work on this issue.

[Gerrit0]

Go for it!

[xuhdev]

There's already a plugin for this: https://typedoc-extra-footer.8hob.io/

[mayank1513]

There's already a plugin for this: https://typedoc-extra-footer.8hob.io/

Please don't avoid adding any features because there is a plugin. Plugins don't work with all versions of Typedoc

[xuhdev]

I don't oppose adding this feature to typedoc. Although architecture-wise I think typedoc should leave these kinds of specialized theme customization options to plugins, even as builtin ones. This is because this feature can be implemented seamlessly with only the hooks exposed to plugins, and doing so can avoid bloating the host system. (I'm happy to adapt the plugin above to a typedoc's builtin plugin, if you think desire.)

As the author of the plugin, with bias, I think the behavior defined in the plugin above is better designed (so I recommend a similar design in the implementation). Specifically,

• If the custom footer and --hideGenerator are both specified, don't hide the custom footer. Instead, add the custom footer after the generator text.
• Wrap the customer footer with a styled <p> tag if the user specified footer is not HTML. This permits users with not much HTML and CSS knowledge to use without struggling making the footer look reasonable.

What do you think? I kinda dislike the situation in which the plugin offers a minor advantage when the host system already offers the core features, so I'm striving to improve the situation so that I can abolish the plugin altogether. 😂

[mayank1513]

I am more interested in adding markdown pages to the documentation.

As of now, I just employed a quick hack - https://react18-tools.github.io/react18-global-store/

But, I believe that this is a very important part of documentation and should be supported by the library.

[Gerrit0]

In general, I agree with @xuhdev, the more specialized functionality I can push to plugins, the easier to maintain TypeDoc itself stays, which makes it easier to maintain. I also mostly agree with the builtin plugin approach, though unfortunately it is messier than I'd like due to other constraints (options are all declared in one place for TypeDoc so that http://typedoc.org/schema.json can be easily generated, in 0.26 option descriptions are translated, and I'd really like to not spread the translatable strings all over the place to make it easier for translators)

That said, having worked places where getting plugins for approved software was a nightmare, I think it's important that it be easy to customize TypeDoc without requiring a plugin for everything. This is why the --customCss option exists, despite being easily implemented with a plugin.

I don't love making one option's behavior dependent on another option, as is done in typedoc-plugin-extra-footer, but can't argue with the improved user experience regarding adding the <p> wrapper...

---

@mayank1513 see #2567