# Typedoc > [!note] If [--useTsLinkResolution](options/comments.md#usetslinkresolution) is turned on (the default) this page --- --- title: Declaration References --- # Declaration References > [!note] If [--useTsLinkResolution](options/comments.md#usetslinkresolution) is turned on (the default) this page > likely **does not apply** for your links within comments (though it will be used for > [external documents](./external-documents.md) and for the readme file). Declaration references are used only if that option is > off or TypeScript fails to resolve a link. Some tags like [`{@link}`](tags/link.md) and [`{@inheritDoc}`](tags/inheritDoc.md) can refer to other members of the documentation. These tags use declaration references to name another declaration. TypeDoc's declaration references are slightly different than JSDoc's namepaths. They are based off of the "new" [TSDoc](https://tsdoc.org/pages/spec/overview/) declaration references with slight modifications to make their resolution behavior more closely match the TypeScript language service (e.g. what VSCode does). Declaration references are comprised of an optional module source, a component path, and an optional meaning. ## Module Source The first part of a declaration, up to a `!` is parsed as the module source. This will be taken literally and used to refer to the module name in a multiple entry point documentation site. It should _not_ include the path to the module file. If a declaration reference does not contain a `!`, then it does not contain a module source, and the first part of the declaration reference is the component path. ```ts /** * {@link moduleA!} * {@link "with!bang and \"quoted path\""!} */ ``` ## Component Path After the module source, declaration references contain a component path, which is made up of one or more component names delimitated by a `.`, `#`, or `~`. The deliminator is used to determine how to navigate the project tree. | Deliminator | Behavior | | --- | --- | | `.` | The most general purpose deliminator. It will first try to resolve exports and static class properties, but will also resolve members if no export is found for improved compatibility with TypeScript's resolution. | | `#` | Indicates that the next component is a "member", including class instance properties, interface members, and enum members. | | `~` | Indicates that the next component is an export of a namespace/module. | > [!warning] The TSDoc specification says that `~` traverses via locals. This is > different than TypeDoc's behavior. TypeDoc will treat `~` as a stricter `.` > which only supports navigating to a namespace/module export. It should > generally be avoided in favor of `.` for improved compatibility with VSCode. ```ts // module.ts /** * {@link module!Foo} * {@link Foo} */ export namespace Foo { /** * {@link module!Foo.Bar} * {@link module!Foo~Bar} * {@link Foo~Bar} */ export namespace Bar { /** * {@link module!Foo.Bar.Baz} * {@link module!Foo~Bar~Baz} * {@link Bar~Baz} * {@link Baz} */ export class Baz { /** * {@link Baz#prop} */ prop = 123; /** * {@link Baz.prop} */ static prop = 456; /** * {@link Baz#instanceOnly} * {@link Baz.instanceOnly} also works as there is no conflicting static */ instanceOnly = 789; } } } ``` ### Reference Scope If no module source is specified, by default component paths are resolved relative to the scope where they are declared (note: Modules and namespaces create a new scope. Classes, interfaces, and object types do not). This is sometimes inconvenient if a name is shadowed. To refer to a name with resolution starting in the the root scope, an empty module source can be specified with `!`. ```ts export const Target = 1; export namespace Foo { export const Target = 2; /** * {@link Target} links to 2 * {@link !Target} links to 1 */ export const Source = 3; } ``` While classes and interfaces do not normally create a new scope, the TypeScript language service will check their members for link targets when resolving links starting at the class/interface declaration. TypeDoc mimics this behavior, but be aware that links that do not contain the class/interface name will prefer targets in their normal scope. ```ts export const dup = 1; /** * {@link dup} links to 1 * {@link target} links to 2 * {@link Foo.dup} links to 3 */ export class Foo { target = 2; dup = 3; } ``` ## Meaning The final part of a declaration reference is an optional meaning which can be used to disambiguate references which could otherwise refer to multiple documentation items. The meaning can also be used to refer to a specific overload or type of declaration. The meaning takes one of the following forms: - `:keyword` where `keyword` is described by the list below. - `:keyword(decimal digits)` where `decimal digits` indicates the index of an overloaded meaning - `:(decimal digits)` shorthand for an overloaded meaning - `:decimal digits` shorthand for an overloaded meaning - `:label` where `label` refers to a declaration by its [`{@label}`](./tags/label.md) tag. `label` may contain `A-Z`, `0-9`, and `_` and may not start with a number. Note: This meaning parse is specific to TypeDoc, and is not currently specified by the TSDoc standard. The keywords recognized by TypeDoc are: - `class` - Refers to reflections which represent a class. - `interface` - Refers to reflections which represent an interface. - `type` - Refers to reflections which represent some type. - `enum` - Refers to reflections which represent an enum. - `namespace` - Refers to reflections which represent a namespace. - `function` - Refers to reflections which represent a function's or method's signatures. - `var` - Refers to reflections which represent a variable. - `constructor` - Refers to the constructor of a class or type. - `member` - Refers to reflections which represent an enum member, property, method, or accessor. - `event` - Permitted to conform with the TSDoc spec, but will result in a broken reference. - `call` - Refers to reflections which represent a function's or method's signatures. - `new` - Refers to the constructor of a class or type. - `index` - Refers to a reflection's index signatures. - `complex` - Refers to reflections which represent some type. - `getter` - (TypeDoc specific, 0.23.3+) Refers to the get signature of an accessor. - `setter` - (TypeDoc specific, 0.23.3+) Refers to the set signature of an accessor. ```ts /** * {@link foo:0} * {@link foo:function} * {@link foo:(0)} * {@link foo:function(0)} * {@link foo:NO_ARGS} * {@label NO_ARGS} */ function foo(): void; /** * {@link foo:1} * {@link foo:function(1)} * {@link foo:(1)} * {@link foo:NUM_ARG} * {@label NUM_ARG} */ function foo(n: number): number; /** * {@link foo:2} * {@link foo:function(2)} * {@link foo:(2)} * {@link foo:STR_ARG} * {@label STR_ARG} */ function foo(s: string): string; ``` --- --- title: Development children: - plugins.md - themes.md - internationalization.md - third-party-symbols.md - local-storage.md --- # Development This page is a work in progress overview of TypeDoc's architecture. For more details about each individual component, refer to the doc comments within each module. It is intended primarily for those interested in contributing to the TypeDoc codebase or developing a plugin. ## High Level TypeDoc follows several high level steps when called. 1. Read options - Necessary to determine which plugins should be loaded. 2. Load plugins 3. Read options again to pick up plugin options 4. Convert the input files into the models (also called reflections) that live under `src/lib/models` 5. Resolve the models
Necessary to handle links to models that might not have been created when the source model is generated. 6. Output the models by serializing to HTML and/or JSON TypeDoc's code is loosely organized according to each of these steps. The code to read options lives under `src/lib/utils/options`. The plugin loading code lives in `src/lib/utils/plugins`. Conversion is performed according to the Symbol's `ts.SymbolFlags`. Each distinct flag type gets its own converter function in `src/lib/converter/symbols.ts`. Resolution is implemented entirely by internal plugins that live in `src/lib/output/plugins` and listen to the `Converter.EVENT_RESOLVE` event. Output is split into two folders, for JSON output see the `src/lib/serialization` directory, and for HTML output see `src/lib/output`. Plugins may effect any part of the process after step 2 by listening to events fired by each component or adding / replacing handlers for a given task. As an example, the [Converter](https://typedoc.org/api/classes/Converter.html) fires events before starting conversion, when declarations are converted and when the project should be resolved. ## Tests TypeDoc has tests for individual utilities and some components, but the majority of the project is tested by converting source files into their JSON model and comparing it to a known good version. The basic example under `src/test/renderer/testProject` is rendered to HTML to test theme changes. If changing the behavior of a converter or resolver, it should be possible to modify one of the existing tests under `src/test/converter`. Bug fixes or feature additions which need to change one of the `specs*.json` files should run `pnpm rebuild_specs [converter|renderer] [converter filter]` to run the current build of TypeDoc on the source files and generate new specs. For other components, we use [Mocha](https://mochajs.org/) to write tests. ### Running the Visual Regression Tests When making changes to the themes, it is useful to be able to compare screenshots from the new/old runs. 1. Run `node scripts/visual_regression.js` 2. Make the UI change 3. Run `node scripts/visual_regression.js` The visual regression script accepts several arguments to control what it does, run it with `--help` to see a summary of the available options. ## Components For more detailed information about the implementation and API surface of each component, consult its API documentation. All components are available on the [Application](https://typedoc.org/api/classes/Application.html) class, which is passed to plugins. ### Options TypeDoc provides some 30 options which determine how the project model is generated and output to disk. The [Options](https://typedoc.org/api/classes/Configuration.Options.html) class consolidates application options into a single location and handles type conversion. There are 11 builtin option types as specified by the [ParameterType](https://typedoc.org/api/enums/Configuration.ParameterType.html) enum. - `String` - A string - `Path` - A string which will be resolved to a path. Paths in config files will be resolved relative to the config directory. - `Number` - A number which is not `NaN` - `Boolean` - `true` or `false` - `Map` - Defines a map between string keys and an arbitrary type. See the [tests](https://github.com/TypeStrong/typedoc/blob/master/src/test/utils/options/declaration.test.ts#L39) for an example. - `Mixed` - An object type that is passed through by TypeDoc to create specific implicit behavior. - `Object` - An object type of which value keys can be overridden or extended by passing a new object. - `Array` - An array of strings. - `PathArray` - An array of paths, if specified in a config file, will be resolved relative to the config file directory. - `ModuleArray` - An array of modules/paths. Items will be resolved if they start with `.`. - `GlobArray` - An array of globs. Globs will be resolved if they do not start with `**`, after skipping leading `!` and `#` characters. Options are discovered and set by option readers, which are documented in the [Configuration.OptionsReader](https://typedoc.org/api/interfaces/Configuration.OptionsReader.html) interface. Plugins can declare their own options by calling [Options.addDeclaration](https://typedoc.org/api/classes/Configuration.Options.html#adddeclaration) ### Plugins Plugins should export a `load` function which will be called by TypeDoc when loading the plugin with an instance of `PluginHost`. This function should add any options the plugin accepts and add any listeners necessary to effect TypeDoc's behavior. ```typescript import { Application, Context, Converter, ParameterType } from "typedoc"; export function load(app: Application) { app.options.addDeclaration({ name: "plugin-option", help: "Displayed when --help is passed", type: ParameterType.String, // The default defaultValue: "", // The default }); app.converter.on(Converter.EVENT_RESOLVE, (context: Context) => { if (app.options.getValue("plugin-option") === "something") { // ... } }); } ``` ### Converters TypeDoc converts the syntax tree created by TypeScript into its own structure of [Reflections](https://typedoc.org/api/classes/Models.Reflection.html) to allow themes and serialization to work with a standard object format. Conversion is done primarily in three files. - [symbols.ts](https://github.com/TypeStrong/typedoc/blob/master/src/lib/converter/symbols.ts) - contains converters for each `ts.Symbol` that is exported from entry points. - [types.ts](https://github.com/TypeStrong/typedoc/blob/master/src/lib/converter/types.ts) - contains converters for `ts.Type`s and `ts.TypeNode`s. - [jsdoc.ts](https://github.com/TypeStrong/typedoc/blob/master/src/lib/converter/jsdoc.ts) - contains converters for types and symbols declared within JSDoc comments. ### JSON Output TypeDoc can produce JSON output which can be consumed by other tools. The format of this JSON is defined by the [JSONOutput.ProjectReflection](https://typedoc.org/api/interfaces/JSONOutput.ProjectReflection.html) interface. If plugins want to cause custom properties to be included in the output JSON, they can achieve this by adding a serializer to [Serializer](https://typedoc.org/api/classes/Serializer.html). If custom properties are added, they should generally also be revived with a [Deserializer](https://typedoc.org/api/classes/Deserializer.html) so that they can be used with TypeDoc's packages mode. ### HTML Output See [Custom Themes](./themes.md) for creating a theme. --- --- title: "Internationalization" group: Guides --- # Internationalization TypeDoc 0.26 added support for internationalization in TypeDoc's output. This is controlled by the `--lang` option and will affect both console output and the generated HTML or JSON output. ## Adding a Locale Locales are stored in TypeDoc's `src/lib/internationalization/locales` directory with the exception of the default locale, which is stored in `src/lib/internationalization/translatable.ts`. To add a new locale, create a file under the `locales` directory which looks like this: ```ts // zh.cts import { buildTranslation } from "../translatable"; export = buildTranslation({ docs_generated_at_0: "文档生成于 {0}", }); ``` This will give a compiler error on `buildTranslation` since the translation object does not provide a translation for every string supported by TypeDoc. Submitting an incomplete translation is still greatly appreciated! If the translation is not complete when submitting for review, import and call `buildIncompleteTranslation` instead. Any strings which are not added to the translation object will automatically fall back to the default English string. The [TranslatableStrings](https://typedoc.org/api/interfaces/TranslatableStrings.html) interface has documentation on the format of TypeDoc's builtin translations. In short, translation keys include numbers to indicate placeholders in the English string, and the translated strings should include `{n}` where the placeholder will be filled in at runtime. > [!IMPORTANT] > Please do not submit machine generated translations for languages you are unfamiliar with. > TypeDoc relies on contributors to ensure the accuracy of included translations. ### Validation The `buildTranslation` and `buildIncompleteTranslation` functions will attempt to validate that the provided translation strings include the same number of placeholders as the default locale. This can check that a string does not miss a placeholder, but will not catch usage of placeholders which will not be defined by TypeDoc. That issue will automatically be caught by a unit test if it occurs. The builder functions will also validate that translations do not provide keys which are not present in the default locale if a fresh object is provided directly to them as suggested in the example above. ## Translating Plugin Defined Strings Plugins may use TypeDoc's internationalization module to provide multiple translations for strings declared within them. To do this, they should call [Application.internationalization.addTranslations] with their expected values. The `addTranslations` method expects that all translatable strings have been declared in the `TranslatableStrings` interface. To do this, use declaration merging to define the expected number of placeholders for each translation string. ```ts import * as td from "typedoc"; declare module "typedoc" { interface TranslatableStrings { // Define a translatable string with no arguments plugin_example_hello_world: []; // Define a translatable string requiring one argument // By convention, keys should include index numbers for each placeholder plugin_example_hello_0: [string]; } } export function load(app: td.Application) { app.internationalization.addTranslations("en", { plugin_example_hello_world: "Hello World!", plugin_example_hello_0: "Hello {0}!", }); app.logger.info(app.i18n.plugin_example_hello_world()); // Logs "Hello World!" app.logger.info(app.i18n.plugin_example_hello_0("TypeDoc")); // Logs "Hello TypeDoc!" } ``` [Application.internationalization.addTranslations]: https://typedoc.org/api/classes/Internationalization.Internationalization.html#addtranslations --- --- title: Disabling Local Storage --- # Disabling Local Storage TypeDoc uses local storage by default to retain operational state information across page loads for components such as side menus, site menus, and generated pages. To comply with certain functional cookie requirements, local storage usage can be toggled using the `window.TypeDoc` object. To disable local storage, use: `window.TypeDoc.disableLocalStorage();` **Note:** Disabling local storage will clear its contents. To enable local storage, use: `window.TypeDoc.enableLocalStorage();` **Note:** Local storage is enabled by default. To disable local storage without clearing it, use: `window.TypeDoc.disableWritingLocalStorage();` --- --- title: Plugins summary: Overview of how to write a TypeDoc plugin --- # Writing a TypeDoc Plugin TypeDoc supports plugins which can modify how projects are converted, how converted symbols are organized, and how they are displayed, among other things. Plugins are Node modules which export a single `load` function that will be called by TypeDoc with the [Application] instance which they are to be attached to. Plugins should assume that they may be loaded multiple times for different applications, and that a single load of an application class may be used to convert multiple projects. Plugins may be either ESM or CommonJS, but TypeDoc ships with ESM, so they should generally published as ESM to avoid `require(esm)` experimental warnings. ```js // @ts-check import * as td from "typedoc"; /** @param {td.Application} app */ export function load(app) { // Add event listeners to app, app.converter, etc. // this function may be async } ``` Plugins affect TypeDoc's execution by attaching event listeners to one or many events that will be fired during conversion and rendering. Events are available on the [Application], [Converter], [Renderer], and [Serializer]/[Deserializer] classes. There are static `EVENT_*` properties on those classes which describe the available events. The best way to learn what's available to plugins is to browse the docs, or look at the source code for existing plugins. There is a list of currently supported plugins at https://typedoc.org/guides/plugins/ TypeDoc also provides several control hooks for plugins to change it's behavior, they are described by the [third party symbols](./third-party-symbols.md) and [custom themes](./themes.md) documents. Plugins which are configurable can add custom options with `app.options.addDeclaration`. [typedoc-plugin-mdn-links] has an example of the recommended way of doing this. If you have specific questions regarding plugin development, please open an issue or ask in the [TypeScript Discord] #typedoc channel. [typedoc-plugin-mdn-links]: https://github.com/Gerrit0/typedoc-plugin-mdn-links/blob/main/src/index.ts [TypeScript Discord]: https://discord.gg/typescript [Application]: https://typedoc.org/api/classes/Application.html [Converter]: https://typedoc.org/api/classes/Converter.html [Renderer]: https://typedoc.org/api/classes/Renderer.html [Serializer]: https://typedoc.org/api/classes/Serializer.html [Deserializer]: https://typedoc.org/api/classes/Deserializer.html --- --- title: Custom Themes --- # Custom Themes Themes are defined by plugins calling the `defineTheme` method on `Application.renderer` when plugins are loaded. The most trivial theme, which exactly duplicates the default theme can be created by doing the following: ```ts import { Application, DefaultTheme } from "typedoc"; export function load(app: Application) { app.renderer.defineTheme("mydefault", DefaultTheme); } ``` This isn't very interesting since it exactly duplicates the default theme. Most themes need to adjust the templates in some way. This can be done by providing them class which returns a different context class. Say we wanted to replace TypeDoc's default footer with one that mentioned your copyright. This could be done with the following theme. In this case, it would probably be better to add this content using a render hook for `footer.begin` or `footer.end`, but it can be done in this way as well. ```tsx import { Application, DefaultTheme, JSX, PageEvent, Reflection } from "typedoc"; class MyThemeContext extends DefaultThemeRenderContext { // Important: If you use `this`, this function MUST be bound! Template functions // are free to destructure the context object to only grab what they care about. override footer = (context) => { return ( ); }; } class MyTheme extends DefaultTheme { getRenderContext(pageEvent: PageEvent) { return new MyThemeContext(this, pageEvent, this.application.options); } } export function load(app: Application) { app.renderer.defineTheme("open-web-analytics", MyTheme); } ``` ## Hooks When rendering themes, TypeDoc's default theme will call several functions to allow plugins to inject HTML into a page without completely overwriting a theme. Hooks live on the parent `Renderer` and may be called by child themes which overwrite a helper with a custom implementation. As an example, the following plugin will cause a popup on every page when loaded. ```tsx import { Application, JSX } from "typedoc"; export function load(app: Application) { app.renderer.hooks.on("head.end", () => ( )); } ``` For documentation on the available hooks, see the [RendererHooks] documentation on the website. ## Async Jobs Themes which completely override TypeDoc's builtin renderer may need to perform some async initialization or teardown after rendering. To support this, there are two arrays of functions available on `Renderer` which plugins may add a callback to. The renderer will call each function within these arrays when rendering and await the results. ```ts import { Application, RendererEvent } from "typedoc"; export function load(app: Application) { app.renderer.preRenderAsyncJobs.push(async (output: RendererEvent) => { app.logger.info( "Pre render, no docs written to " + output.outputDirectory + " yet", ); // Slow down rendering by 1 second await new Promise((r) => setTimeout(r, 1000)); }); app.renderer.postRenderAsyncJobs.push(async (output: RendererEvent) => { app.logger.info( "Post render, all docs written to " + output.outputDirectory, ); }); } ``` ## Registering your own custom elements/attributes Custom JSX elements can be defined by merging with TypeDoc's `IntrinsicElements` interface. TypeScript will pick up properties of this interface as valid element names. ```ts import { Application, JSX } from "typedoc"; declare module "typedoc" { // JSX.JSX is intentional due to TypeScript's strange JSX type discovery rules namespace JSX.JSX { interface IntrinsicElements { "custom-button": IntrinsicAttributes & { target: string; }; } // Generally shouldn't be necessary, TypeDoc contains an interface // with all attributes documented on MDN. Properties added here will // be permitted on all JSX elements. interface IntrinsicAttributes { customGlobalAttribute?: string; } } } export function load(app: Application) {} ``` [RendererHooks]: https://typedoc.org/api/interfaces/RendererHooks.html --- --- title: Third Party Symbols --- # Third Party Symbols TypeDoc 0.22 added support for linking to third party sites by associating a symbol name with npm packages. Since TypeDoc 0.23.13, some mappings can be defined without a plugin by setting [`externalSymbolLinkMappings`][externalSymbolLinkMappings]. This should be set to an object whose keys are package names, and values are the `.` joined qualified name of the third party symbol. If the link was defined with a user created declaration reference, it may also have a `:meaning` at the end. TypeDoc will _not_ attempt to perform fuzzy matching to remove the meaning from keys if not specified, so if meanings may be used, a url must be listed multiple times. Global external symbols are supported, but may have surprising behavior. TypeDoc assumes that if a symbol was referenced from a package, it was exported from that package. This will be true for most native TypeScript packages, but packages which rely on `@types` will be linked according to that `@types` package for that package name. Furthermore, types which are defined in the TypeScript lib files (including `Array`, `Promise`, ...) will be detected as belonging to the `typescript` package rather than the `global` package. In order to support both `{@link !Promise}` and references to the type within source code, both `global` and `typescript` need to be set. ```jsonc // typedoc.json { "externalSymbolLinkMappings": { // For these you should probably install typedoc-plugin-mdn-links instead "global": { // Handle {@link !Promise} "Promise": "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise", }, "typescript": { // Handle type X = Promise "Promise": "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise", }, }, } ``` A wildcard can be used to provide a fallback link to any unmapped type. ```jsonc // typedoc.json { "externalSymbolLinkMappings": { "external-lib": { "SomeObject": "https://external-lib.site/docs/SomeObject", "*": "https://external-lib.site/docs", }, }, } ``` ## Plugins Plugins can add support for linking to third party sites by calling [Converter.addUnknownSymbolResolver] If the given symbol is unknown, or does not appear in the documentation site, the resolver may return `undefined` and no link will be rendered unless provided by another resolver. The string `"#"` may also be returned to indicate that TypeDoc should mark the symbol as externally resolved, but not produce a link to it. This can be useful if you want to keep the link for usage in VSCode, but not include it in the documentation. The following plugin will resolve a few types from React to links on the official React documentation site. ```ts import { Application, type DeclarationReference } from "typedoc"; const knownSymbols = { Component: "https://reactjs.org/docs/react-component.html", PureComponent: "https://reactjs.org/docs/react-api.html#reactpurecomponent", }; export function load(app: Application) { app.converter.addUnknownSymbolResolver((ref: DeclarationReference) => { if ( // TS defined symbols ref.moduleSource !== "@types/react" && // User {@link} tags ref.moduleSource !== "react" ) { return; } // If someone did {@link react!}, link them directly to the home page. if (!ref.symbolReference) { return "https://reactjs.org/"; } // Otherwise, we need to navigate through the symbol reference to // determine where they meant to link to. Since the symbols we know // about are all a single "level" deep, this is pretty simple. if (!ref.symbolReference.path) { // Someone included a meaning, but not a path. // https://typedoc.org/guides/declaration-references/#meaning return; } if (ref.symbolReference.path.length === 1) { const name = ref.symbolReference.path[0].path; if (knownSymbols.hasOwnProperty(name)) { return knownSymbols[name as never]; } } }); } ``` Since TypeDoc 0.23.26, plugins may also return return an object for more control over the displayed link. The returned `caption` will be used if the user does not specify the link text. ```ts import { Application, type DeclarationReference } from "typedoc"; const documentedExports = [ "chunk", "compact", "concat", "difference", "differenceBy", "differenceWith", ]; export function load(app: Application) { app.converter.addUnknownSymbolResolver((ref: DeclarationReference) => { if ( // TS defined symbols ref.moduleSource !== "@types/lodash" && // User {@link} tags ref.moduleSource !== "lodash" ) { return; } // If someone did {@link lodash!}, link them directly to the home page. if (!ref.symbolReference) { return "https://lodash.com/"; } if (!ref.symbolReference.path) { // Someone included a meaning, but not a path. // https://typedoc.org/guides/declaration-references/#meaning return; } if (ref.symbolReference.path.length === 1) { const name = ref.symbolReference.path[0].path; if (documentedExports.includes(name)) { return { target: `https://lodash.com/docs/4.17.15#${name}`, caption: name, }; } } }); } ``` The unknown symbol resolver will also be passed the reflection containing the link and, if the link was defined by the user, the [Models.CommentDisplayPart] which was parsed into the [DeclarationReference] provided as the first argument. If `--useTsLinkResolution` is on (the default), it may also be passed a [Models.ReflectionSymbolId] referencing the symbol that TypeScript resolves the link to. [externalSymbolLinkMappings]: https://typedoc.org/options/comments/#externalsymbollinkmappings [Converter.addUnknownSymbolResolver]: https://typedoc.org/api/classes/Converter.html#addUnknownSymbolResolver [Models.CommentDisplayPart]: https://typedoc.org/api/types/Models.CommentDisplayPart.html [DeclarationReference]: https://typedoc.org/api/interfaces/DeclarationReference.html [Models.ReflectionSymbolId]: https://typedoc.org/api/classes/Models.ReflectionSymbolId.html --- --- title: Doc Comments children: - jsdoc-support.md - tsdoc-support.md --- # Doc Comments TypeDoc implements a minimal parser for your comments which extracts TSDoc/JSDoc tags and recognizes code blocks to ignore decorators. The resulting markup after resolving tags is then passed to the [markdown-it](https://github.com/markdown-it/markdown-it) markdown parser to be converted to HTML. ```ts /** * This comment _supports_ [Markdown](https://www.markdownguide.org/) */ export class DocumentMe {} ``` TypeDoc will ignore comments containing `@license` or `@import`. ## Code Blocks TypeDoc supports code blocks in markdown and uses [Shiki](https://shiki.matsu.io/) to provide syntax highlighting. You can specify the syntax highlighting theme with the [`--lightHighlightTheme`](../options/output.md#lighthighlighttheme) and [`--darkHighlightTheme`](../options/output.md#darkhighlighttheme) options. TypeDoc only loads some of the languages supported by Shiki by default. If you want to load additional languages, use the [`highlightLanguages`](../options/output.md#highlightlanguages) option. ````ts /** * Code blocks are great for examples * * ```ts * // run typedoc --help for a list of supported languages * const instance = new MyClass(); * ``` */ export class MyClass {} ```` > [!note] > TypeDoc only supports fenced code blocks. Indentation based code blocks will not prevent tags > from being parsed within the code block. ## Escaping Comments TypeDoc supports escaping special characters in comments to include literal `{}@/` characters. All other escapes will be passed through to be processed by markdown-it. As an example: ````ts /** * This is not a \@tag. Nor is this an \{\@inlineTag\} * * It is possible to escape the end of a comment: * ```ts * /** * * docs for `example()` * *\/ * function example(): void * ``` */ ```` Will be rendered as: > This is not a \@tag. Nor is this an \{\@inlineTag\} > > It is possible to escape the end of a comment: > > ```ts > /** > * docs for `example()` > */ > function example(): void; > ``` ## Comment Discovery In most cases, TypeDoc's comment discovery closely mirrors TypeScript's discovery. If a comment is placed directly before a declaration or typically belongs to a declaration but lives on a parent node, TypeDoc will include it in the documentation. ```ts /** * This works * @param x this works */ function example(x: string, /** This too */ y: number) {} /** This also works */ class Example2 {} ``` TypeDoc also supports discovering comments in some locations which TypeScript does not. 1. Comments on type aliases directly containing unions may have comments before each union branch to document the union. ```ts type Choices = /** Comment for option 1 */ | "option_1" /** Comment for option 2 */ | { option_1: number }; ``` 2. Comments on export specifiers which export (or re-export) a member. ```ts /** A comment here will take precedence over a module comment in Lib */ export * as Lib from "lib"; ``` Comments on export specifiers only have higher priority than the module comment for modules and references where the symbol appears in the documentation multiple times. ```ts export * as Lib from "lib"; // Use the @module comment /** Preserved for backwards compatibility, prefer {@link Lib} */ export * as Library from "lib"; /** This comment will be used for someFunction only if someFunction does not have a comment directly on it */ export { someFunction } from "lib"; ``` ## See Also - The [Tags overview](../tags.md) - The [Declaration References](../declaration-references.md) guide - The [TSDoc](https://tsdoc.org/) website --- --- title: JSDoc Support --- # JSDoc Support JSDoc is the de-facto "standard" for comments, but does not specify a rigorous grammar and is fully implemented only by the official JSDoc tool. TypeDoc aims to recognize _most_ JSDoc comments in a manner similar to how they are handled by TypeScript and Visual Studio Code. Where the JSDoc implementation conflicts with the TSDoc specification, TypeDoc generally tries to detect which implementation is intended. JSDoc compatibility can be controlled with the [--jsDocCompatibility](../options/comments.md#jsdoccompatibility) option. ## Notable Differences - TypeDoc's [`@link`](../tags/link.md) tags do not support JSDoc namepaths - TypeDoc does not require type annotations in [`@param`](../tags/param.md) blocks - TypeDoc does not parse [`@see`](../tags/see.md) tag contents as links - TypeDoc does not support all JSDoc tags --- --- title: TSDoc Support --- # TSDoc Support The TSDoc standard is a proposal to standardize parsing of JSDoc-like comments. TypeDoc aims to be compliant with the TSDoc standard, but does not enforce it. This means that while TypeDoc should be able to parse all (or nearly all) TSDoc-complaint comments, it does not require that your comments follow the standard. This approach has several benefits, including better support for projects originally written using JSDoc and support for more markdown constructs (including day-to-day features like [headings](https://github.com/microsoft/tsdoc/issues/197), and [lists](https://github.com/microsoft/tsdoc/issues/178)). However, for projects requiring stricter validation of comment formats, this laxness may not be acceptable. In this case, [api-extractor](https://api-extractor.com/) is recommended instead of TypeDoc for it's much stricter conformance to TSDoc. ## Notable Differences - The [jsDocCompatibility](../options/comments.md#jsdoccompatibility) option can be used to configure TypeDoc to parse comments more similarly to JSDoc/TypeScript than TSDoc. - TypeDoc takes advantage that TSDoc syntax is (with the exception of tags) a subset of markdown, so delegates most comment parsing to its markdown parser. - The [`@inheritDoc`](../tags/inheritDoc.md) tag is declared as an inline tag by TSDoc, but TypeDoc recognizes it in block tag form as well for compatibility with JSDoc. - The [`@label`](../tags/label.md) tag has been extended to support user specified meanings in declaration references. - The [`@link`](../tags/link.md) tag may be parsed with either TSDoc's [declaration references](../declaration-references.md) or with TypeScript's resolution. - The [`@param`](../tags/param.md) tag supports ignoring type annotations in order to support TypeScript's types-in-comments capability. - The [`@privateRemarks`](../tags/privateRemarks.md) tag may be configured to be included in the documentation. - The [`@public`](../tags/public.md) tag is not inherited by contained members. - The [`@typeParam`](../tags/typeParam.md) tag supports ignoring type annotations in order to support TypeScript's types-in-comments capability. --- --- title: External Documents --- It can be convenient to write long-form guides/tutorials outside of doc comments. To support this, TypeDoc supports including documents which exist as standalone `.md` files in your repository. ## Including Documents These documents can be included in your generated documentation in a few ways. 1. With the [`@document`](tags/document.md) tag. 2. With the [projectDocuments] option. 3. As a child of another document using yaml frontmatter. ### The `@document` Tag The `@document` tag can be placed in the comments for most types to add a child to that reflection in the generated documentation. The content of the `@document` tag should simply be a path to a markdown document to be included in the site. ```ts /** * @document documents/external-markdown.md */ ``` The document path is relative to the file in which the comment appears in. ### Project Documents If your project has multiple entry points, the `@document` tag cannot be used to place documents at the top level of the project as there is no comment location associated with the project. For this use case, specify the [projectDocuments] option. This option can be specified multiple times, or a glob may be specified to include multiple documents. ```json // typedoc.json { "projectDocuments": ["documents/*.md"] } ``` TypeDoc's default [sorting](options/organization.md#sort) options will cause project documents to be re-ordered alphabetically. If not desired, sorting for entry points can be disabled with the [sortEntryPoints](options/organization.md#sortentrypoints) option. ## Document Content Documents may include a yaml frontmatter section which can be used to control some details about the document. Note: The frontmatter **must** begin and end with `---` on lines by itself. TypeDoc's frontmatter extraction uses this to determine when the block ends. ```yaml --- title: External Markdown group: Documents category: Guides children: - ./child.md - ./child2.md --- ``` The `title` key specifies the document name, which will be used in the sidebar navigation. The `group` and `category` keys are equivalent to the [`@group`](tags/group.md)and [`@category`](tags/category.md) tags and control how the document shows up in the Index section on the page for the reflection which owns the document. The `children` key can be used to specify additional documents which should be added underneath the current document. Documents may include relative links to images or other files/documents. TypeDoc will detect links within markdown `[text](link)` formatted links, `` tags and `` tags and automatically resolve them to other documents in the project. if a path cannot be resolved to a part of the documentation, TypeDoc will copy the file found to a `media` folder in your generated documentation and update the link to point to it, so relative links to images will still work. Documents may also include `{@link}` inline tags, which will be resolved as [declaration references](declaration-references.md) by TypeDoc. [projectDocuments]: options/input.md#projectdocuments --- TypeDoc converts comments in TypeScript's source code into HTML documentation or a JSON model. ## Quick Start TypeDoc generates documentation based on your exports. It will follow re-exports to document members declared in other files for each entry point. ```bash # Install npm install --save-dev typedoc # Build docs using package.json "exports" or "main" fields as entry points npx typedoc ``` If TypeDoc is unable to discover your entry points, they can be provided manually: ```bash # Build docs using exports from src/index.ts npx typedoc src/index.ts ``` If you are documenting an application rather than a library, which doesn't have a single entry point, you may want to document each file individually. ```bash # Generate docs for all TypeScript files under src npx typedoc --entryPointStrategy Expand src ``` TypeDoc supports a variety of [options](./options.md) and [themes](./themes.md). It is extensible via the [plugin API](./plugins.md). --- --- title: Comments --- These options control how TypeDoc parses comments. ## commentStyle ```bash $ typedoc --commentStyle block ``` Determines what comment types TypeDoc will use. Note: Writing non-JSDoc comments will cause poorer intellisense in VSCode and is therefore generally not recommended. | Value | Behavior | | --------------- | -------------------------------------- | | jsdoc (default) | Use block comments starting with `/**` | | block | Use all block comments | | line | Use `//` comments | | all | Use both block and line comments | ## useTsLinkResolution ```bash $ typedoc --useTsLinkResolution false ``` Indicates that `{@link}` tags should be resolved with TypeScript's parsing rules. This is on by default. ## preserveLinkText ```bash $ typedoc --preserveLinkText false ``` Indicates whether or not `{@link}` tags should include just the name of the target reflection, or the original link text. This is on by default. ## jsDocCompatibility CLI: ```bash $ typedoc --jsDocCompatibility false $ typedoc --jsDocCompatibility.defaultTag false ``` typedoc.json (defaults): ```json { "jsDocCompatibility": { "exampleTag": true, "defaultTag": true, "inheritDocTag": true, "ignoreUnescapedBraces": true } } ``` JSDoc specifies that the `@example` and `@default` tags indicate that the following content should be parsed as code. This conflicts with the TSDoc standard. With this option on, TypeDoc will attempt to infer from the tag content whether it should be parsed as code by checking if the tag content contains a code block. TSDoc specifies that `@inheritdoc` should be spelled with a capitalized `D`, `@inheritDoc`. If `inheritDocTag` is set to `false`, TypeDoc will produce a warning when rewriting `@inheritdoc` to `@inheritDoc`. TSDoc specifies that braces (`{}`) must be escaped within comments to avoid ambiguity between the start of an inline tag and a brace to be included in the rendered text. TypeDoc's `ignoreUnescapedBraces` option determines if warnings are emitted if a brace is found within regular comment text without being escaped. ## suppressCommentWarningsInDeclarationFiles ```bash $ typedoc --suppressCommentWarningsInDeclarationFiles ``` Prevents warnings due to unspecified tags from being reported in comments within `.d.ts` files. ## blockTags ```json // typedoc.json { "blockTags": ["@param", "@returns"] } ``` This specifies all of the [block tags](../tags.md#block-tags) that TypeDoc considers to be valid. TypeDoc will warn when it finds an unknown tag. If you need to add a custom one, you can extend the defaults by using a JavaScript configuration file: ```js import { OptionDefaults } from "typedoc"; /** @type {Partial} */ const config = { // Other config here. // ... blockTags: [...OptionDefaults.blockTags, "@foo"], }; export default config; ``` Note that this option will be set by `tsdoc.json`, if present. (Using a `tsdoc.json` file is an alternate way to add a custom tag.) Also see [`inlineTags`](#inlinetags) and [`modifierTags`](#modifiertags). ## inlineTags ```json // typedoc.json { "inlineTags": ["@link"] } ``` This specifics all of the [inline tags](../tags.md#inline-tags) that TypeDoc considers to be valid. TypeDoc will warn when it finds a non-valid tag. If you need to add a custom one, you can extend the defaults by using a JavaScript configuration file: ```js import { OptionDefaults } from "typedoc"; /** @type {Partial} */ const config = { // Other config here. // ... inlineTags: [...OptionDefaults.inlineTags, "@foo"], }; export default config; ``` Note that this option will be set by `tsdoc.json`, if present. (Using a `tsdoc.json` file is an alternate way to add a custom tag.) Also see [`blockTags`](#blocktags) and [`modifierTags`](#modifiertags). ## modifierTags ```json // typedoc.json { "modifierTags": ["@hidden", "@packageDocumentation"] } ``` This specifics all of the [modifier tags](../tags.md#modifier-tags) that TypeDoc considers to be valid. TypeDoc will warn when it finds a non-valid tag. If you need to add a custom one, you can extend the defaults by using a JavaScript configuration file: ```js import { OptionDefaults } from "typedoc"; /** @type {Partial} */ const config = { // Other config here. // ... modifierTags: [...OptionDefaults.modifierTags, "@foo"], }; export default config; ``` Note that this option will be set by `tsdoc.json`, if present. (Using a `tsdoc.json` file is an alternate way to add a custom tag.) Also see [`blockTags`](#blocktags) and [`inlineTags`](#inlinetags). ## cascadedModifierTags ```json // typedoc.json { "modifierTags": ["@alpha", "@beta", "@experimental"] } ``` Specifies modifier tags which should be copied to all children of the parent reflection. Note that `@deprecated` is a block tag, not a modifier tag, so should not be specified here. ## excludeTags ```bash $ typedoc --excludeTags @apidefine ``` Specify tags that should be removed from doc comments when parsing. Useful if your project uses [apiDoc](https://apidocjs.com/) for documenting RESTful web APIs. ## notRenderedTags ```bash $ typedoc --notRenderedTags @beta ``` Specify tags which should be preserved in the doc comments, but not rendered when creating output. This is intended to support tags which carry some meaning about how to render a member or instructions for TypeDoc to do something after a package has been deserialized from JSON in packages mode. ## preservedTypeAnnotationTags ```json // typedoc.json { "preservedTypeAnnotationTags": ["@fires"] } ``` Specify block tags whose type annotations should be preserved by TypeDoc's parser, leading to their content being included in the rendered documentation. ## externalSymbolLinkMappings ```json // typedoc.json { // format: { [packageName: string]: { [exportName: string]: string } } "externalSymbolLinkMappings": { // {@link typescript!Partial} will use this link as well as // type Foo = Partial "typescript": { "Partial": "https://www.typescriptlang.org/docs/handbook/utility-types.html#partialtype" } } } ``` Can be used to specify locations of externally defined types. If the external library uses namespaces, qualify the name with `.` as a separator. These definitions will be used for both types linked to by the user via a `{@link}` tag and in code. TypeDoc assumes that if a symbol was referenced from a package, it was exported from that package. This will be true for most native TypeScript packages, but packages which rely on `@types` will be linked according to the `@types` package, not the original module name. If both are intended to be supported, both packages must be listed. ```json // typedoc.json { "externalSymbolLinkMappings": { // used by `class Foo extends Component {}` "@types/react": { "Component": "https://reactjs.org/docs/react-component.html" }, // used by {@link react!Component} "react": { "Component": "https://reactjs.org/docs/react-component.html" } } } ``` Global external types are supported, but may have surprising behavior. Types which are defined in the TypeScript lib files (including `Array`, `Promise`, ...) will be detected as belonging to the `typescript` package rather than the special `global` package reserved for global types. ```json // typedoc.json { "externalSymbolLinkMappings": { // used by {@link !Promise} "global": { "Promise": "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise" }, // used by type Foo = Promise "typescript": { "Promise": "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise" } } } ``` The string `"#"` may also be specified to indicate to TypeDoc that the type should be marked as resolved but no link should be created. ```json // typedoc.json { "externalSymbolLinkMappings": { // used by {@link !Promise} "global": { "Promise": "#" }, // used by type Foo = Promise "typescript": { "Promise": "#" } } } ``` --- --- title: Configuration --- These options control where TypeDoc reads its configuration from. TypeDoc will read options from the [options](#options) file, the `"typedocOptions"` key in your `package.json` file, and a `"typedocOptions"` key in your tsconfig.json. All paths within configuration files are resolved relative to the options file they are specified within. ## options ```bash typedoc --options ``` Specify a configuration file to be loaded, which should contain entries that correspond to command-line options/flags. If not specified, TypeDoc will look for a configuration file matching one of the valid config names in the current directory: - typedoc.json - typedoc.jsonc - typedoc.config.js - typedoc.config.cjs - typedoc.config.mjs - typedoc.js (avoid this name, Windows CMD will try to run it instead of calling TypeDoc when running from that directory) - typedoc.cjs - typedoc.mjs - The same filenames under the `.config` directory, `.config/typedoc.json`, ... Option files may also contain an extends key, which specifies an additional file to be loaded before importing options from the current file. ### JSON Files If you are using a `typedoc.json` file, VSCode should automatically pick up the schema. If it does not, you can instruct your editor to pick up the schema with a `$schema` key. ```json { "$schema": "https://typedoc.org/schema.json", "entryPoints": ["./src/index.ts", "./src/secondary-entry.ts"], "out": "doc" } ``` Like `tsconfig.json`, JSON configuration files are parsed as JSONC, which means that you can safely use trailing commas and comments in your file. ### JavaScript Files If you are using a JavaScript file for options, it should export an object whose keys are the option names. For example: ```js /** @type {Partial} */ const config = { entryPoints: ["./src/index.ts", "./src/secondary-entry.ts"], out: "doc", }; export default config; ``` ## tsconfig ```bash typedoc --tsconfig tsconfig.json ``` Specify a `tsconfig.json` file that options should be read from. If not specified TypeDoc will look for `tsconfig.json` in the current directory and parent directories like `tsc` does. When TypeDoc loads a `tsconfig.json` file, it will also read TypeDoc options declared under the `"typedocOptions"` key and look for a `tsdoc.json` file in the same directory to read supported tags. See [TSDoc Support](../doc-comments/tsdoc-support.md) for details on how to use a `tsdoc.json` file. ## compilerOptions This option may only be set within a config file. ```jsonc // typedoc.json { "compilerOptions": { "skipLibCheck": true, "strictNullChecks": false, }, } ``` Used to selectively override compiler options for generating documentation. TypeDoc parses code using the TypeScript compiler and will therefore behave similarly to tsc. Values set with this option will override options read from tsconfig.json. See [#1891](https://github.com/TypeStrong/typedoc/pull/1891) for details. ## plugin ```bash typedoc --plugin typedoc-plugin-markdown typedoc --plugin ./custom-plugin.js ``` Specifies the plugins that should be loaded. By default, no plugins are loaded. See [Plugins](../plugins.md) for a list of available plugins. If using a JavaScript configuration file, the `plugin` option may be given a function which will be called to load a plugin. --- --- title: Input --- These options control what files TypeDoc processes to generate documentation and how the files are processed. ## entryPoints ```bash typedoc src/index.ts src/alt.ts # or typedoc --entryPoints src/index.ts --entryPoints src/alt.ts ``` ```jsonc // typedoc.json { "entryPoints": ["src/index.ts", "src/alt.ts", "src/multiple/*.ts"], } ``` Specifies the entry points globs to be documented by TypeDoc. TypeDoc will examine the exports of these files and create documentation according to the exports. Entry points can be handled in one of four ways, see [--entryPointStrategy](#entrypointstrategy) for details. If this option is not set, TypeDoc will automatically discover your entry points according to the ["exports"](https://nodejs.org/api/packages.html#exports) or ["main"](https://nodejs.org/api/packages.html#main) fields in your package.json, using your tsconfig options to map the JavaScript files back to the original TypeScript source. If a `"typedoc"` [conditional export](https://nodejs.org/api/packages.html#conditional-exports) is used, TypeDoc will use it instead of the `"import"` export condition. The set of entry points provided to TypeDoc determines the names displayed in the documentation. By default, TypeDoc will derive a [displayBasePath](output.md#displaybasepath) based on your entry point paths to determine the displayed module name, but it can be also be set with the [`@module`](../tags/module.md) tag. ## entryPointStrategy ```bash typedoc --entryPointStrategy expand ./src ``` Specifies how specified entry points should be handled. ### resolve (default) Expects all entry points to be contained within the root level tsconfig project. If a directory is given, includes `/index` as the entry point. ### expand (default prior to v0.22.0) Expects all entry points to be contained within the root level tsconfig project. If a directory is given, its contents are recursively expanded and treated as entry points. ### packages Expects all entry points to be directories to _effectively_ run TypeDoc within. After each entry point has been converted by TypeDoc to a JSON model, the projects will be merged together and rendered to a single site or JSON output. Each package may have its own set of TypeDoc configuration, but `plugins` within sub-projects will _not_ be loaded. See [Gerrit0/typedoc-packages-example](https://github.com/Gerrit0/typedoc-packages-example) for an example monorepo which uses this option. > [!warning] When running in packages mode, options must be specified in the > correct location. As TypeDoc effectively runs with a clean options object for > each directory, options which take effect during conversion must be set within > [packageOptions](#packageoptions) or directly within configuration for each > project. Configuration specified in the root level project will _not_ be > copied to child projects. See the [package options](package-options.md) page > for documentation about where each option should be set. ### merge Expects all entry points to be `.json` files generated with a previous run of TypeDoc with the [`--json`](./output.md#json) option set. These entry points will be merged into a single project. ## packageOptions ```json // typedoc.json { "entryPointStrategy": "packages", "entryPoints": ["packages/*"], "packageOptions": { "entryPoints": ["src/index.ts"] } } ``` Options to set be set within each package when entryPointStrategy is set to packages. Unlike most options in TypeDoc, paths within this object are interpreted relative to the package directory. This option has no effect if [entryPointStrategy](#entrypointstrategy) is not set to `packages`. ## alwaysCreateEntryPointModule By default, if TypeDoc is given only one entry point, it will place exports of that entry point directly within the generated project. If this option is specified, TypeDoc will instead always create a module for the entry point. Has no effect if more than one entry point is passed to TypeDoc. If [`--projectDocuments`](#projectdocuments) is used to add documents, this option defaults to `true`, otherwise, defaults to `false`. ```bash typedoc --alwaysCreateEntryPointModule ``` ## projectDocuments Specify additional markdown documents to be added to the generated documentation site. See the [External Documents](../external-documents.md) guide for more details. ```json // typedoc.json { "projectDocuments": ["docs/tutorial.md"] } ``` ## exclude ```bash typedoc --exclude "**/*+(index|.spec|.e2e).ts" ``` Exclude files by the given pattern when a path is provided as source. This option is only used to remove files from consideration as entry points. Unlike TypeScript's `exclude` option, it _cannot_ be used to exclude files from compilation. You may want to turn on TypeScript's [--skipLibCheck](https://www.typescriptlang.org/tsconfig#skipLibCheck) if you have compilation errors originating in `@types` packages. **Important:** To exclude files or paths entirely, use TypeScript's `exclude` option in your `tsconfig.json`. TypeDoc will not include any files excluded by `tsconfig.json`. See [issue #1928](https://github.com/TypeStrong/typedoc/issues/1928#issuecomment-1121047065) for further discussion. Supports [minimatch](https://github.com/isaacs/minimatch) patterns. In configuration files, this option accepts an array of patterns. On the command line, it may be specified multiple times to add multiple patterns. If an exported member from one of your entry points is located in an excluded file, it will be excluded from the documentation. If `entryPointStrategy` is set to `packages`, then you can specify package directories with this option to exclude from documentation. ## externalPattern ```bash typedoc --externalPattern 'lib/**/*.ts' --externalPattern 'external/**/*.ts' ``` Define patterns for extra files that should be considered external. Can be used along with `--excludeExternals` to remove external modules from the documentation. ## excludeExternals ```bash typedoc --excludeExternals ``` Prevent externally resolved TypeScript files from being documented. Defaults to false. ## excludeNotDocumented ```bash typedoc --excludeNotDocumented ``` Removes symbols from the generated documentation which do not have an associated doc comment if they are matched by `excludeNotDocumentedKinds`. ## excludeNotDocumentedKinds ```json // typedoc.json { "excludeNotDocumented": true, "excludeNotDocumentedKinds": ["Property", "Interface", "TypeAlias"] } ``` Specifies the kinds of member which can be removed by `excludeNotDocumented`. Defaults to: ```json { "excludeNotDocumentedKinds": [ "Module", "Namespace", "Enum", // "EnumMember", // Not enabled by default "Variable", "Function", "Class", "Interface", "Constructor", "Property", "Method", "CallSignature", "IndexSignature", "ConstructorSignature", "Accessor", "GetSignature", "SetSignature", "TypeAlias", "Reference" ] } ``` ## excludeInternal ```bash typedoc --excludeInternal ``` Removes symbols annotated with the `@internal` doc tag. Defaults to true if the stripInternal compiler option is set to true, otherwise defaults to false. ## excludePrivate ```bash typedoc --excludePrivate ``` Removes members marked with `private` and `#private` class fields from the generated documentation. Defaults to true. To include `#private` class fields both this option and [excludePrivateClassFields](#excludeprivateclassfields) must be set to `false`. ## excludePrivateClassFields ```bash typedoc --excludePrivateClassFields ``` Removes `#private` class fields from the generated documentation. Defaults to true. ## excludeProtected ```bash typedoc --excludeProtected ``` Removes protected class members from the generated documentation. Defaults to false. ## excludeReferences ```bash typedoc --excludeReferences ``` Removes re-exports of a symbol already included in the documentation from the documentation. Defaults to false. ## excludeCategories ```bash typedoc --excludeCategories A --excludeCategories B ``` Removes reflections associated with any of the given categories. ## maxTypeConversionDepth ```bash typedoc --maxTypeConversionDepth 2 ``` Specifies the maximum depth to recurse when converting types, defaults to `10`. ## name ```bash typedoc --name ``` Set the name of the project that will be used in the header of the template. The name defaults to the package name according to your `package.json`. ## includeVersion ```bash typedoc --includeVersion ``` Includes the version according to `package.json` in generated documentation. Defaults to false. ## disableSources ```bash typedoc --disableSources ``` Disables capturing where reflections are declared when converting input. ## sourceLinkTemplate ```bash typedoc --sourceLinkTemplate 'https://vcs.example.com/{path}?at={gitRevision}#line={line}' ``` Has no effect if `--disableSources` is set. Specify a link template to be used when generating source urls. If not set, will be automatically created using the git remote for GitHub, GitLab, and BitBucket urls. Supports `{path}`, `{line}`, and `{gitRevision}` placeholders. ## gitRevision ```bash typedoc --gitRevision ``` Has no effect if `--disableSources` is set. Use specified revision or branch instead of the last revision for linking to source files. Defaults to the last commit. Accepts the special value `{branch}` to indicate that `{gitRevision}` in `sourceLinkTemplate` should be set to the current commit branch. If `gitRevision` is set to `{branch}` and the current HEAD is not set to the tip of a branch, TypeDoc will use the last commit instead. ## gitRemote ```bash typedoc --gitRemote ``` Has no effect if `--disableSources` is set. Use the specified git remote instead of `origin` for linking to source files in GitHub, Bitbucket, or GitLab. You can use `git remote` to view a list of valid remotes. If you are updating documentation for a forked package, you probably want to pass `--gitRemote upstream`. ## disableGit ```bash typedoc --disableGit ``` Prevents TypeDoc from using Git to try to determine if sources can be linked, with this enabled, sources will always be linked, even if not part of a git repo. ## readme ```bash typedoc --readme ``` Path to the readme file that should be displayed on the index page. If set to `none`, or no readme file is automatically discovered, the index page will be disabled. ## basePath ```bash typedoc --basePath ./ ``` Path to a directory containing asset files which will be checked when resolving relative paths of links and images within documentation comments and external documents. If specified, this will also be used for the default value of the [displayBasePath](output.md#displaybasepath) option. --- --- title: Organization --- These options control how content is structured on generated pages. ## groupReferencesByType ```bash $ typedoc --groupReferencesByType ``` Specifies that re-exports to a member already included in the documentation should be grouped under the type that the referenced member is grouped within. By default, TypeDoc will group these references in a `References` group. ## categorizeByGroup ```bash $ typedoc --categorizeByGroup ``` This flag categorizes reflections by group (within properties, methods, etc). To allow methods and properties of the same category to be grouped together, set this flag to false. Defaults to false. ## defaultCategory ```bash $ typedoc --defaultCategory "Category Name" ``` Sets the name for the default category which is used when only some elements of the page are categorized. Defaults to 'Other' ## categoryOrder ```json // typedoc.json { "categoryOrder": ["Category Name", "Other Category", "*"] } ``` Array option which allows overriding the order categories display in. A string of `*` indicates where categories that are not in the list should appear. Categories whose order is not specified will be sorted alphabetically. If `*` is not specified and unknown categories are found, they will be listed at the end by default. A category called `none` (case-insensitive) is reserved and treated specially by the default theme to be displayed without a category before other categories. ## groupOrder ```json // typedoc.json { "groupOrder": ["Variables", "Functions", "*"] } ``` Array option which allows overriding the order groups display in. A string of `*` indicates where groups that are not in the list should appear. Groups whose order is not specified will be sorted alphabetically. If `*` is not specified and unknown groups are found, they will be listed at the end by default. A group called `none` (case-insensitive) is reserved and treated specially by the default theme to be displayed without a group heading before list of groups. ## sort ```bash $ typedoc --sort static-first --sort alphabetical ``` Specifies the sort order for members. Sorting strategies will be applied in order. If an earlier sorting strategy determines the relative ordering of two reflections, later ordering strategies will not be applied. This option defines the default sort strategy, the [`@sortStrategy`](../tags/sortStrategy.md) tag may be used to override it for individual reflections. For example, with the setting `["static-first", "visibility"]`, TypeDoc will first compare two reflections by if they are static or not, and if that comparison returns equal, will check the visibility of each reflection. On the other hand, if `["visibility", "static-first"]` is specified, TypeDoc would sort all public properties first and then sort each group to put static properties first. This means that `["source-order", "static-first"]` is equivalent to `["source-order"]` since ordering by position in source will always produce a non-equal comparison. The available sorting strategies are: - `source-order` (sorts by file, then by position in file) - `alphabetical` - `enum-value-ascending` (only applies to children of an enum) - `enum-value-descending` (only applies to children of an enum) - `static-first` - `instance-first` - `visibility` (public, then protected, then private) - `required-first` - `kind` (order according to the `kindSortOrder` option) - `external-last` - `documents-first` - `documents-last` - `alphabetical-ignoring-documents` The default sort order is: ```json { "sort": [ "kind", "instance-first", "alphabetical-ignoring-documents" ] } ``` ## sortEntryPoints ```bash $ typedoc --sortEntryPoints false ``` By default, TypeDoc sorts the members of all pages according to the `sort` option, this option can be used to disable sorting at the top level. ## kindSortOrder Specifies the relative ordering of reflections if `kind` is specified in the `sort` option. The default order is: ```json // typedoc.json { "kindSortOrder": [ "Reference", "Project", "Module", "Namespace", "Enum", "EnumMember", "Class", "Interface", "TypeAlias", "Constructor", "Property", "Variable", "Function", "Accessor", "Method", "Parameter", "TypeParameter", "TypeLiteral", "CallSignature", "ConstructorSignature", "IndexSignature", "GetSignature", "SetSignature" ] } ``` --- --- title: Other --- Options which don't fit elsewhere. ## watch ```bash $ typedoc --watch ``` Use TypeScript's incremental compiler to watch source files for changes and build the docs on change. May be combined with `--emit`. This mode detects changes to project documents, readme, custom JS/CSS, configuration files, files imported by `@include`/`@includeCode`, and any files explicitly registered by plugins as needing to be watched, as well as all your TypeScript source files. Watch mode is not supported with `entryPointStrategy` set to `packages` or `merge`. ## preserveWatchOutput ```bash $ typedoc --watch --preserveWatchOutput ``` By default, `--watch` clears the screen between compilation steps. If `--preserveWatchOutput` is specified, this behavior is disabled. ## help ```bash $ typedoc --help ``` Print all available options, along with a short description. Also prints a list of supported highlighting languages. ## version ```bash $ typedoc --version ``` Prints TypeDoc's version. ## showConfig ```bash $ typedoc --showConfig ``` Print TypeDoc's config and exit. Useful for debugging what options have been set. ## logLevel ```bash $ typedoc --logLevel Verbose ``` Specifies the log level to be printed to the console. Defaults to `Info`. The available levels are: - Verbose - Print all log messages, may include debugging information intended for TypeDoc developers - Info - Print informational log messages along with warning and error messages - Warn - Print warning and error messages - Error - Print only error messages - None - Print no messages. ## skipErrorChecking ```bash $ typedoc --skipErrorChecking ``` Instructs TypeDoc to not run the type checker before converting a project. Enabling this option may improve generation time, but could also result in crashes if your code contains type errors. --- --- title: Output --- These options control TypeDoc's output. ## outputs ```json // typedoc.json { "outputs": [ { "name": "html", "path": "./docs_html" }, { "name": "html", "path": "./docs_html_full_nav", "options": { "navigation": { "includeCategories": true, "includeGroups": true, "excludeReferences": false, "includeFolders": true } } }, { "name": "json", "path": "./docs.json" }, { // requires typedoc-plugin-markdown "name": "markdown", "path": "./docs_markdown" } ] } ``` Specifies the outputs which should be rendered by TypeDoc. Outputs specify the name of the output type, a path to render it to, and optionally a set of options to be set when rendering the output. The output types which ship with TypeDoc by default are `html` and `json`. Note that any option may be set in the `options` key, but if the option is used during conversion rather than output it will have no effect when rendering the output. ## out ```bash $ typedoc --out ``` Specifies the location the default output type should be written to. By default, this will cause TypeDoc to generate HTML documentation, but this option may be used by plugins (like [typedoc-plugin-markdown](https://www.npmjs.com/package/typedoc-plugin-markdown)) which change the default output type. This option is an output shortcut. If specified, the [outputs](#outputs) option will be overwritten by this option and any other specified output shortcuts. ## html ```bash $ typedoc --html ``` Specifies the location the html documentation should be written to. The HTML output produced by running TypeDoc on itself can be seen at [TypeDoc API](https://typedoc.org/api/) This option is an output shortcut. If specified, the [outputs](#outputs) option will be overwritten by this option and any other specified output shortcuts. This entire site is generated using TypeDoc's [external document](../external-documents.md) support to include markdown documents alongside the API documentation. ## json ```bash $ typedoc --json ``` Specifies the location to output a JSON file containing all of the reflection data. An example of the JSON output from running TypeDoc on itself can be seen at [/media/docs.json](../../docs/docs.json). This option is an output shortcut. If specified, the [outputs](#outputs) option will be overwritten by this option and any other specified output shortcuts. ## pretty ```bash $ typedoc --json out.json --pretty ``` Tells TypeDoc to pretty-format the JSON output. Defaults to true. ## emit ```bash $ typedoc --emit none ``` Instructs TypeDoc to write compiled output files as `tsc` does. | Value | Behavior | | ------ | ---------------------------------------------- | | `docs` | Emit documentation, but not JS (default). | | `both` | Emit both documentation and JS. | | `none` | Emit nothing, just convert and run validation. | > [!note] > If TypeScript is configured with `declaration: true` (through `tsconfig.json`) > then the TypeDoc emit `both` option will also generate type declaration files. ## theme ```bash $ typedoc --theme default ``` Specify the theme name that should be used. ## router ```bash $ typedoc --router default ``` Specify the router that should be used to determine what files to create for the HTML output and how to link between pages. Additional routers may be added by plugins/themes. TypeDoc ships with the following builtin routers: - **kind** (default) - Creates folders according to their the documented member's kind. - **kind-dir** - Like **kind**, but renders each page as `index.html` within a directory for the page name. This can be used to make "clean" urls. - **structure** - Creates folders according to the module structure. - **structure-dir** - Like **structure**, but renders each page as `index.html` within a directory for the page name. This can be used to make "clean" urls. - **group** - Creates folders according to the reflection's [`@group`](../tags/group.md). - **category** - Creates folders according to the reflection's [`@category`](../tags/category.md). This is easiest to understand with an example. Given the following API: ```ts export function initialize(): void; /** @group Opts */ export class Options {} export namespace TypeDoc { export const VERSION: string; } ``` TypeDoc will create a folder structure resembling the following, the common `assets` folder and `index.html` / `modules.html` files have been omitted for brevity. **kind** ```text docs ├── classes │ └── Options.html ├── functions │ └── initialize.html ├── modules │ └── TypeDoc.html └── variables └── TypeDoc.VERSION.html ``` **structure** ```text ├── initialize.html ├── Options.html ├── TypeDoc │ └── VERSION.html └── TypeDoc.html ``` **groups** ```text docs ├── Opts │ └── Options.html ├── Functions │ └── initialize.html ├── Namespaces │ └── TypeDoc.html └── Variables └── TypeDoc.VERSION.html ``` ## lightHighlightTheme ```bash $ typedoc --lightHighlightTheme light-plus ``` Specify the Shiki theme to be used to highlight code snippets in light mode. ## darkHighlightTheme ```bash $ typedoc --darkHighlightTheme dark-plus ``` Specify the Shiki theme to be used to highlight code snippets in dark mode. ## highlightLanguages Specifies the Shiki grammars to load for highlighting code blocks. By default, TypeDoc loads the following languages. ```json { "highlightLanguages": [ "bash", "console", "css", "html", "javascript", "json", "jsonc", "json5", "tsx", "typescript" ] } ``` ## ignoredHighlightLanguages Specifies languages used in code blocks which should be silently ignored by TypeDoc. By default, TypeDoc will produce a warning if a code block specifies a language which is not present in the highlightLanguages array. ```json { "ignoredHighlightLanguages": ["mkdocs"] } ``` ## typePrintWidth Specifies the width at which to wrap code when rendering types, defaults to 80. Changing this is not advised without tweaks to the theme in use. ```bash typedoc --typePrintWidth 120 ``` ## customCss ```bash $ typedoc --customCss ./theme/style.css ``` Specifies an extra CSS file that should be copied into the assets directory and referenced by the theme. ## customJs ```bash $ typedoc --customJs ./theme/custom.js ``` Specifies a JavaScript script (not module) file that should be copied into the assets directory and referenced by the theme. ## customFooterHtml ```bash $ typedoc --customFooterHtml "Copyright Project 2024" ``` Specifies additional custom HTML which should be injected into the page footer. ## customFooterHtmlDisableWrapper ```bash $ typedoc --customFooterHtml "

Copyright Project 2024

" --customFooterHtmlDisableWrapper ``` By default, TypeDoc will wrap the custom footer HTML in a `

` element to allow plain text added with it to show up properly aligned. This option disables the wrapping. ## markdownItOptions Specifies the options that are forwarded to [markdown-it](https://github.com/markdown-it/markdown-it) when parsing doc comments. By default TypeDoc overrides the default values used by markdown-it with the ones shown below: ```json { "markdownItOptions": { "html": true, "linkify": true } } ``` See the [options section](https://github.com/markdown-it/markdown-it?tab=readme-ov-file#init-with-presets-and-options) in the markdown-it readme for a full list of available options. ## markdownItLoader Function which can be set in a JS config file to configure plugins loaded by `markdown-it`. It will be called with an instance of the [`MarkdownIt`](https://markdown-it.github.io/markdown-it/#MarkdownIt) class. ```js // typedoc.config.mjs export default { markdownItLoader(parser) { parser.use(plugin1); }, }; ``` ## displayBasePath ```bash $ typedoc --displayBasePath ./ --entryPoints src/index.ts ``` Specifies the base path to be used when displaying file paths. If not set, TypeDoc will guess by taking the lowest common directory to all source files. In the above example, TypeDoc would display links to `index.ts` rather than `src/index.ts` if `displayBasePath` was not specified. Defaults to the value of [basePath](input.md#basepath) > [!note] > This option only affects displayed paths. It _does not_ affect where TypeDoc will create links to. ## cname ```bash $ typedoc --cname typedoc.org ``` Create a CNAME file in the output directory with the specified text. ## favicon ```bash $ typedoc --favicon favicon.ico ``` Specify a `.ico`, `.png` or `.svg` file to reference as the site favicon. ## sourceLinkExternal ```bash $ typedoc --sourceLinkExternal ``` Treat source links as external links that open in a new tab when generating HTML. ## markdownLinkExternal ```bash $ typedoc --markdownLinkExternal ``` Specifies that `http[s]://` links in comments and markdown files should be treated as external links to be opened in a new tab ## lang ```bash $ typedoc --lang zh ``` Sets the `lang` attribute in TypeDoc's HTML output and the translations used when, generating documentation. Defaults to `en`, resulting in ``. ## locales ```json // typedoc.json { "locales": { "zh": { "flag_private": "私有" } } } ``` Specify translations which TypeDoc will used when `--lang` is set to the specified locale. See [translatable.ts](https://github.com/TypeStrong/typedoc/blob/master/src/lib/internationalization/translatable.ts) for a list of all potentially translated messages within TypeDoc. If your translations may be generally useful to the community, please consider submitting a pull request adding them to TypeDoc! ## githubPages ```bash $ typedoc --githubPages false ``` When enabled, automatically add a `.nojekyll` file to the output directory to prevent GitHub Pages from processing your documentation site using Jekyll. If you have scoped packages, TypeDoc generates HTML files that start with `_` which are ignored by Jekyll. Defaults to `true`. ## cacheBust ```bash $ typedoc --cacheBust ``` When enabled, TypeDoc will include the generation time in `