Is there a way to document just functions?

/**
 * This is my func.
 */
export const myFunc = () => {};

tracking

As far as I can tell, documentalist does not generate information about accessors in classes.

class Example {
  get x() {
    return 1;
  }
}

In this example, the accessor x is not documented. This is a bug in my opinion because documentations for projects that use accessors commonly will lack many details.

docs site does not load on IE 11 because source uses some ES6 syntax features like arrow functions and classes.

• constructor type info #49
• static members in interfaces #49
• get files in order #50
• README #52
• enum type: Kind.Class, not just Class #53
• index signatures! { [key: string]: IType } #59
• sourceUrl field is better than fileName #60
• type arguments in class name
• release notes
• windows build #35
• client interfaces consumption
• output built files in /lib/ paths instead of /dist/

This is a regression in v5.0.0 caused by #156

Previously, @default tag values on interface properties would just contain the text of the default value:

Now in v5.0.0, we get extra markup around the value which is unnecessary and should be stripped out in the output:

like "CHARGES" in this classic stripe docs screenshot:

The TypeScript plugin skips all files in node_modules. I have a use case where my API re-uses interfaces from a dependency, but I can't include definitions of that interface because all node_modules are ignored.

Hey all,

Any plans on supporting Utility Types such as Partial<Foo> or Omit<Foo, 'bar'>? Is there a trick I'm missing? Thanks!

example: https://palantir.github.io/documentalist/#IRoute

Hi,

I was wondering if there is a way to extract the line-numbers of the methods, classes, and interfaces. within a TypeScript file?

Thanks.

I'm not sure if this is intentional or not, but the lerna.json has:

"userWorkspaces": true,

I'm pretty sure that should be:

"useWorkspaces": true,

If that's correct, I can make a PR trivially.

Given a file _nav.md

---
menu: [
  {
    icon: faHome,
    page: Home
  }
]
---
Don't delete this text,
this file has to contain something besides metaData for it to be parsed by documentalist.

The metadata will only be parsed if the file has Unix LF line endings. If the file has Windows CR LF or Mac CR it will fail to parse the metadata.

Currently I'm using the compiler. I use the compiler to build JSON, which I then use to create markdown. According to https://jsdoc.app/tags-event.html, I should be able to use @event tags to document different events that are emitted.

Desired usage:

/**
 * @event Drawer:event Emits when the drawer has closed.
 * @type {object}
 * @event Drawer:opened Emits when the drawer has opened.
 * @type {object}
 */
export class Drawer {

Actual Result:
Using this notation actually removes the Drawer entry from docs.json.

ts-quick-docs is stuck on [email protected] and each version bump requires a complete re-engineering of the parser. for instance, 2.1 -> 2.2 has huge changes to how jsdoc tags are processed and I simply can't figure out the new compiler APIs to access them, so I can't upgrade ts-q-d.

I propose we kill ts-q-d and use typedoc directly for all our typescript doc'ing needs. this'll require some serious work but should future-proof the project and reduce the maintenance burden going forward.

How would I add inline typedoc tags such as {@link}?

I want to use documentalist on a TypeScript-only project. I don't want to download kss and its dependencies.

circle 1.0 will be shut down in August 2018.

in code it's IPanel<P> but the type arg does not appear in the interface table. (does appear on member properties though.)

This is a regression in v5.0.0 caused by #156

Previously, we were easily able to include JSDoc comment markdown containing inline code snippets on interface properties.

This comment:

    /**
     * Props to pass to the query [InputGroup component](#core/components/input-group).
     *
     * Some properties are unavailable:
     * - `inputProps.value`: use `query` instead
     * - `inputProps.onChange`: use `onQueryChange` instead
     * - `inputProps.disabled`: use `disabled` instead
     * - `inputProps.fill`: use `fill` instead
     *
     * Other notes:
     * - `inputProps.tagName` will override `popoverProps.targetTagName`
     * - `inputProps.className` will work as expected, but this is redundant with the simpler `className` prop
     */

Would get parsed as the following markdown string:

'Props to pass to the [InputGroup component](#core/components/input-group).

Some properties are unavailable:
- `inputProps.value`: use `value` instead
- `inputProps.disabled`: use `disabled` instead
- `inputProps.type`: cannot be customized, always set to "text"

Note that `inputProps.tagName` will override `popoverProps.targetTagName`.'

Which would get easily rendered by marked to the following HTML:

<p>Props to pass to the query <a href="#core/components/input-group">InputGroup component</a>.</p>
<p>Some properties are unavailable:</p>
<ul>
<li><code>inputProps.value</code>: use <code>query</code> instead</li>
<li><code>inputProps.onChange</code>: use <code>onQueryChange</code> instead</li>
<li><code>inputProps.disabled</code>: use <code>disabled</code> instead</li>
<li><code>inputProps.fill</code>: use <code>fill</code> instead</li>
</ul>
<p>Other notes:</p>
<ul>
<li><code>inputProps.tagName</code> will override <code>popoverProps.targetTagName</code></li>
<li><code>inputProps.className</code> will work as expected, but this is redundant with the simpler <code>className</code> prop</li>
</ul>

Now, there's a bug where each inline code snippet gets put on its own line, which breaks markdown rendering. The JSDoc comment above gets parsed as:

`Props to pass to the [InputGroup component](#core/components/input-group).

Some properties are unavailable:
- 
`inputProps.value`
: use 
`value`
 instead
- 
`inputProps.disabled`
: use 
`disabled`
 instead
- 
`inputProps.type`
: cannot be customized, always set to "text"

Note that 
`inputProps.tagName`
 will override 
`popoverProps.targetTagName`
.'

Which results in this bad rendered HTML:

<p>Props to pass to the query <a href="#core/components/input-group">InputGroup component</a>.</p>
<h2>Some properties are unavailable:</h2>
<h2><code>inputProps.value</code>
: use 
<code>query</code>
 instead</h2>
<h2><code>inputProps.onChange</code>
: use 
<code>onQueryChange</code>
 instead</h2>
<h2><code>inputProps.disabled</code>
: use 
<code>disabled</code>
 instead</h2>
<p><code>inputProps.fill</code>
: use 
<code>fill</code>
 instead</p>
<h2>Other notes:</h2>
<p><code>inputProps.tagName</code>
 will override 
<code>popoverProps.targetTagName</code></p>
<p>- 
<code>inputProps.className</code>
 will work as expected, but this is redundant with the simpler 
<code>className</code>
 prop</p>

Which renders in Blueprint's docs like this:

This is likely a TypeDoc bug.

It would be nice with a new release with update dependencies. Some dependencies like marked are quite old. I could do a PR to update as many none breaking dependencies as possible, if someone are ready to review and hopefully merge the changes.

Hey all. I’d realllllllly like to use this instead of storybook. I know that the React plugin and all is in blueprint source, but it seems heavily tied into blueprint’s build / gulp tasks. It would be nice if documentalist came with React support and an example of a React theme / output out of the box.

Consider using libnpm instead of spawning npm process in npm plugin

Every piece of information that is currently used by npm plugin can be acquired through libnpm without using npm cli directly.

versions property is sorted by npm cli view command (https://github.com/npm/cli/blob/656bce7dd0f9753a273912e803261ed246593924/lib/view.js#L50)

const packument = require('libnpm/packument');
const semver = require('semver');

packument('libnpm', {
    fullMetadata: true
}).then((data) => {
    const distTags = data["dist-tags"] || {};
    console.log({
        name: data.name,
        description: data.description,
        latestVersion: distTags.latest,
        nextVersion: distTags.next,
        versions: Object.keys(data.versions).sort(semver.compareLoose),
    });
});

which doesn't work in IE11 without transpilation. this caused palantir/blueprint#3463

npx documentalist "src/**/*"

node version: 6

Error: Unknown @page '_nav' in toTree()
    at PageMap.toTree (_npx/61470/lib/node_modules/documentalist/dist/page.js:55:19)
    at MarkdownPlugin.compile (_npx/61470/lib/node_modules/documentalist/dist/plugins/markdown.js:42:27)
    at _npx/61470/lib/node_modules/documentalist/dist/documentalist.js:127:69
    at step (_npx/61470/lib/node_modules/documentalist/dist/documentalist.js:38:23)
    at Object.next (_npx/61470/lib/node_modules/documentalist/dist/documentalist.js:19:53)
    at step (_npx/61470/lib/node_modules/documentalist/dist/documentalist.js:23:97)
    at Object.next (_npx/61470/lib/node_modules/documentalist/dist/documentalist.js:19:53)
    at _npx/61470/lib/node_modules/documentalist/dist/documentalist.js:13:71
    at __awaiter (_npx/61470/lib/node_modules/documentalist/dist/documentalist.js:9:12)
    at Documentalist.documentFiles (_npx/61470/lib/node_modules/documentalist/dist/documentalist.js:114:16)
    at Documentalist.<anonymous> (_npx/61470/lib/node_modules/documentalist/dist/documentalist.js:102:44)
    at step (_npx/61470/lib/node_modules/documentalist/dist/documentalist.js:38:23)
    at Object.next (_npx/61470/lib/node_modules/documentalist/dist/documentalist.js:19:53)
    at _npx/61470/lib/node_modules/documentalist/dist/documentalist.js:13:71
    at __awaiter (_npx/61470/lib/node_modules/documentalist/dist/documentalist.js:9:12)
    at Documentalist.documentGlobs (_npx/61470/lib/node_modules/documentalist/dist/documentalist.js:98:16)

It's all in the title.

[email protected]

npm audit fix output

fixed 0 of 3 vulnerabilities in 7084 scanned packages
3 vulnerabilities required manual review and could not be updated

npm audit output

=== npm audit security report ===
Manual Review
Some vulnerabilities require your attention to resolve
Visit https://go.npm.me/audit-guide for additional guidance

found 3 vulnerabilities (1 low, 2 moderate) in 7084 scanned packages
3 vulnerabilities require manual review. See the full report for details.

This is a regression in v5.0.0 caused by #156

Previously, types without generic type params were rendered as expected, without any <> type params list:

Now, they often include an extraneous & unnecessary empty type params list, which can mislead users to believe that the type is generic: