Typedoc: Instruct typedoc which kind of symbols need distinct files

[jsamr]

First of all, I want to be grateful for the amazing work and energy put in this project. It is really super helpful!

I am having a bit of a struggle with the tool: the distinction between how typedoc handles, on one hand, functions, type aliases and variables and on the other hand, classes, enums and interfaces seems arbitrary.

Looks like it creates individual files for the later group, and flushes anything else in a "globals" file. I have read the documentation, and haven't seen anything that could meet my needs.

Is there any way I can change this behavior, and have let's say all symbols in one unique page, or have functions and variables in separate files?

[Gerrit0]

Version 0.19:

This is determined by the Theme class. The theme class has a getUrls function which returns a UrlMapping for each contained document that should be rendered. The DefaultTheme will create a new page for classes, interfaces, enums, namespaces, and modules. The MinimalTheme is simpler since it tries to put everything in one page.

To override this, you need to make a custom theme which contains theme.js in the root directory. This file needs to export a class that will be created by the renderer with module.exports = class ... or export default class ....

Version 1.0 (unreleased):

This is determined by the hasOwnDocument function in the theme's router. There is more info here.

[jsamr]

@Gerrit0 This is a great answer, thank you!

[jsamr]

@Gerrit0 I patched the DefaultTheme class to achieve what I wanted:

diff --git a/dist/lib/output/themes/DefaultTheme.js b/dist/lib/output/themes/DefaultTheme.js
index 46b5fae75b8945d6d1f1b42c8f7025b721e3b61e..80f90e0787aa8b49a0e8ec6a42009d83a3547330 100644
--- a/dist/lib/output/themes/DefaultTheme.js
+++ b/dist/lib/output/themes/DefaultTheme.js
@@ -227,6 +227,22 @@ DefaultTheme.MAPPINGS = [{
         isLeaf: false,
         directory: 'enums',
         template: 'reflection.hbs'
+    },{
+        kind: [index_1.ReflectionKind.Variable],
+        isLeaf: false,
+        directory: 'variables',
+        template: 'reflection.hbs'
+    },{
+        kind: [index_1.ReflectionKind.Function],
+        isLeaf: false,
+        directory: 'functions',
+        template: 'reflection.hbs'
+    }, {
+    },{
+        kind: [index_1.ReflectionKind.TypeAlias],
+        isLeaf: false,
+        directory: 'types',
+        template: 'reflection.hbs'
     }, {
         kind: [index_1.ReflectionKind.Namespace, index_1.ReflectionKind.Module],
         isLeaf: false,

I would love to extend the DefaultTheme class instead; but it looks like there is no way to redefine DefaultTheme.MAPPINGS in a clean fashion. Do you think it would be a good idea that this library provide a "ThemeBuilder" facility to handle such use-case easily? Or do you see a different yet easy pattern for implementing such extension?

[jsamr]

@Gerrit0 A lot of these static methods (getUrls ...) could be refactored to an external class which can be injected by the "ThemeBuilder".

[Gerrit0]

I absolutely think there is room for improvement in how TypeDoc handles themes. I particularly dislike how data about how to render reflections is stored on reflections themselves. The 1.0 rewrite was one attempt to fix that, though it still needs some modification (it doesn't really give a good way to render anything besides html). If you'd like to give making the 0.x theme architecture better, I'd welcome it!

[jsamr]

@Gerrit0 I would be willing to work on such draft, unfortunately my bandwidth is limited as I am already investing a lot of efforts in my own open source projects. I'll eventually work on something if I find the time.