Hi, in the version 0.6.0-0 npm audit reports this one:

I am using typedoc 0.15.0 preview

npm audit                    
                                                                                
                       === npm audit security report ===                        
                                                                                
┌──────────────────────────────────────────────────────────────────────────────┐
│                                Manual Review                                 │
│            Some vulnerabilities require your attention to resolve            │
│                                                                              │
│         Visit https://go.npm.me/audit-guide for additional guidance          │
└──────────────────────────────────────────────────────────────────────────────┘
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ High          │ Cross-Site Scripting (XSS)                                   │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ jquery                                                       │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in    │ >=3.0.0                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ typedoc                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ typedoc > typedoc-default-themes > jquery                    │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://npmjs.com/advisories/328                             │
└───────────────┴──────────────────────────────────────────────────────────────┘

When I glanced at the compiled main.js file from the default theme it had the following at the top:

/*
 * ATTENTION: The "eval" devtool has been used (maybe by default in mode: "development").
 * This devtool is not neither made for production nor for readable output files.
 * It uses "eval()" calls to create a separate source file in the browser devtools.
 * If you are trying to read the output file, select a different devtool (https://webpack.js.org/configuration/devtool/)
 * or disable the default devtool with "devtool: false".
 * If you are looking for production-ready output files, see mode: "production" (https://webpack.js.org/configuration/mode/).
 */

This seems like not desirable behavior.

....Kinda wordy, but - if you use a tag such as @async, then follow it with @description blah blah blah, what is rendered for description's dd is slightly overlapping the rest.

For reference TypeStrong/typedoc#583

I would be willing to go through and remove jQuery from the codebase. Before I do, I just want to know if that would be desired and merged?

Is the class name tsd-parameter-siganture intentional or a bug?

See here and here for its presence in the code base.

I have a rather big index file (around 23.5 MB) and when I try to make a simple search, it takes too long to load any results. Sometimes the page is stuck completely for a minute and sometimes it can take 10 seconds to complete the search. Is there a way to descrease the search time for such a big index file? It is definatly not a networking issue, such thing happens when the index file is completely loaded.

Hi, for latest typedoc-default-themes 0.6.0-0 that is used by typedoc 0.15.0-0, the vulnerable version of dependency jquery was still reported in npm audit. I noticed there is an existing issue TypeStrong/typedoc#994 to track this and jquery was updated to ^3.3.1. But it looks like it needs higher version >=3.4.0 in my npm audit below. Could you please npm audit fix your package and publish to npm?

npm audit output follows:
Moderate Prototype Pollution

Package jquery

Patched in >=3.4.0

Dependency of typedoc [dev]

Path typedoc > typedoc-default-themes > jquery

More info https://nodesecurity.io/advisories/796

High Cross-Site Scripting (XSS)

Package jquery

Patched in >=3.0.0

Dependency of typedoc [dev]

Path typedoc > typedoc-default-themes > jquery

More info https://nodesecurity.io/advisories/328

I don't know much about Handlebars or the TypeDoc build process, but how hard would it be to turn the docs into an SPA? I ask mainly because I've added a dark theme toggle that uses the FilterItem class along with a bunch of CSS variables. The problem is that it flashes white every time you navigate, which is highly unfortunate. I'm pretty sure it's because it has to read from localStorage then set the CSS vars and propagate those down the tree. If it was an SPA, it would only need to read once, which I hope would prevent the flash.

I think the main issue would be doing the routing. I imagine we'd make a new partial called content and switch that out on navigation (probably have to split out .tsd-page-title from header), but the routes would have to be created during the TypeDoc build.

See for example https://docs.convergence.io/js-api/classes/historicalmodel.html#elementat. Clicking a link within the signature definition should navigate to that link, instead it just toggles the currently visible one.

Hi,
hbs file is defined by Express, should I learn Express first?
I have nothing known about hbs

Main problem

I am a developer of reselect-utils. I use typedoc for docs generation. My project is written on Typesript, but I wanted to provide dark theme for my documentation and now half of my codebase is a huge CSS file. I have a some plan to improve it.

Road map

• Migrate from Grunt to webpack - it will allow to bundle TS without namespaces and resolve all static files smarter than just a concatenation.
• Change theme API - now API of this library is collection of template files and two static files (CSS and JS). I propose to expose unbudled TS and SASS files as addition to HBS templates to allow override any part of theme (not only markup). Also I propose to expose some build function, that can receive all theme parts from user and build HTML, CSS and JS from HBS, SASS and TS. It can look like this:

const webpack = require('webpack');

export function buildTheme() {
    return new Promise((resolve, reject) => {
        webpack(webpackConfig, (err, stats) => {
            if (err) {
                return reject(err)
            }
            if (stats.hasErrors()) {
                return reject(new Error(stats.compilation.errors.join('\n')))
            }
            resolve()
        })
    })
}

So, what do you think about that? Will it be useful and helpful?

In my current documentation, I'd like the filters to be displayed with these default values:
visibility: public
inherited: false
externals: true
only-exported: true

but for now, your hardcoded values are
visibility: private
inherited: true
externals: true
only-exported: false

Is there's a way to customize these values through a custom theme ? Or through properties of typedoc build ?

the dropdown does not work. the checkboxes can be toggled but nothing happens. as far as i can see there are no javascript runtime errors being thrown. it seems like the script for the whole filtering is not even being called.

Tell me what you think of this idea: an input field where you can type and it will live filter members on the page.

One idea is to have the filter input above the secondary nav. Another is to somehow multipurpose the current search in the toolbar.

A question would be, do we want to fuzzy search or imperative search?

https://typedoc.org/api/globals.html#preferred

I discovered this while rebasing my derived theme to the latest version from this repo.

Occasionally npm run build will fail with an error such as

Error: ENOENT: no such file or directory, open '<path>/typedoc-default-themes/bin/minimal/partials/toc.hbs'

I believe this is due to the CleanWebpackPlugin() ending up not being the first plugin, as recommended here.

When I try to use the 'Minimal' template, it breaks everything (next fig)

It's not doing that with the 'Default' template :/
Does the same when I merge 'Default' and 'Minimal' template files

Am I doing something wrong or the 'Minimal' template is really broken ?

Hi!
I'm making a dark theme but I don't find the thing that set the color of the code and how to change it, can I get more information on this?

Follow convention and put "repository" link in the right side of the header. Useful when docs are the first search result.

When clicking on search icon I get:

Uncaught TypeError: typedoc.Application is not a constructor
    at typedoc (main.js:5)
    at main.js:5

it's same for both minimal/default theme....

When using the search feature, it's possible to navigate between results and hit enter and be taken to that page. Also, on mobile devices, it's possible to touch a result and be taken to that page. Clicking a result, however, doesn't take the user to the page, which is a big problem.

I imagine this is some sort of issue with jQuery intercepting the click event before the anchor can be processed, but my knowledge in that realm is limited. Does anyone know how to fix this?

EDIT: Even more interesting, a normal-speed click doesn't work, but if the mouseup occurs the instant after mousedown (click very quickly), it correctly navigates to the search result.

Hi and thanks for Typedoc!

It offers an amazing start and I accept I should theme if I need something different. However, thought I should share that for my very simple case the default theme tends to push all the meaningful information 'below the fold' by redundant information which could probably be fixed by changing defaults.

From the top to the bottom, referencing the screenshot above...

• The Lock interface visibly has a generic parameter Key in its declaration. Nevertheless 112 vertical pixels are dedicated to a block containing three words "Type Parameters...Key"
• The Lock interface is a top-level interface with no hierarchy. Nevertheless another 100 pixels are dedicated to a block stating "Hierarchy...Lock"
• The Lock interface is designed with a simple API and single responsibility. It's sole acquire property is already visible in the index in the navigation tree to the right of the page and its full definition would be visible except that 150 pixels are dedicated to a block stating "Index...Properties...acquire".

Combined, these elements push all of the API details out of site below the viewport. I can't help thinking that these cases might be eliminated in more opinionated model-generation or template logic.

A) Is a Generic parameters block necessary given the visible declaration already in the header
B) Is a Hierarchy block for something without a Hierarchy necessary.
C) Is a property index necessary when there are property trees for Lock already rendered to the right. It also takes a lot of prime space. Perhaps it could have less whitespace and vertical structure if it remains?

Thoughts

If I was to approach solving it for my case via typedoc flags or a specialised typedoc theme is there any value in me trying to PR changes back to the main project or themes that you might accept or have been considering anyway?

Alternative View

The alternative view shown below comes from manually deleting the redundant blocks described from the first screenshot. After this change, within the 800 or so vertical pixels the complete API for this interface is visible. It still has some redundancy given the type declaration for acquire shown twice for no obvious reason but it's much better.

The npm clean script will bomb on Windows machines which makes consumers have to handle errors when trying to build on CI or locally.

I plan to submit a PR to add a grunt clean task to replace the Unix commands to avoid any cross-platform errors.