Fact-checked by Grok 2 weeks ago

JSDoc

JSDoc is an API documentation generator for JavaScript that enables developers to create detailed, structured documentation by embedding special comments directly within their source code. These comments follow a standardized syntax inspired by Javadoc, using block-level tags such as @param, @returns, and @type to describe functions, methods, parameters, return values, and other code elements. The tool processes annotated JavaScript files via a command-line interface and outputs professional HTML documentation, often resembling a static website with navigation, search capabilities, and cross-references. Originally developed as a -based tool starting in 2011 by Michael Mathews, JSDoc builds on earlier documentation practices for . The project, hosted on under the 2.0, has evolved through community contributions and now supports modern features including ES6+ modules, async functions, and TypeScript-like type annotations. As of November 2025, the latest stable release is version 4.0.5, compatible with 12.0.0 and later, and it includes plugins for extensions like formatting and custom templates. Beyond basic documentation, JSDoc enhances code maintainability by facilitating tools like autocompletion and type checking in environments such as , where JSDoc annotations serve as a bridge for adding type information to plain files. It is widely adopted in open-source projects and enterprise settings for generating readable references, with configurable options for output formats, source parsing, and integration with build tools like or Gulp. This makes JSDoc a foundational tool in the JavaScript ecosystem, promoting without requiring a separate .

Introduction

Purpose and Scope

JSDoc is an documentation generator for , designed to create structured documentation by embedding special comment blocks directly into . It functions similarly to tools like or phpDocumentor, allowing developers to annotate elements such as modules, namespaces, classes, methods, and parameters within their files. The scope of JSDoc centers on annotating to generate comprehensive documentation, while also supporting advanced features like autocompletion through IntelliSense and enabling static type analysis. By parsing these annotations, JSDoc produces output in formats such as websites, which detail the application's and behavior without requiring separate documentation files. Primary applications of JSDoc include generating navigable documentation sites for projects, enhancing code readability through inline explanations, and promoting team collaboration by standardizing documentation practices that reduce misunderstandings and onboarding time. JSDoc emerged to fulfill the need for structured in dynamic languages like , where traditional type systems are absent.

Key Features

JSDoc enables the addition of type annotations directly within comments, allowing developers to specify types for variables, parameters, returns, and more using tags such as @type, @param, and @typedef. This feature facilitates static type checking when integrated with tools like the Closure Compiler, which interprets these annotations to detect type errors and optimize code during compilation. One of JSDoc's core strengths is its ability to generate structured outputs from inline comments, producing formats such as websites, data, or files. By running the JSDoc command-line tool on , it automatically parses comments and renders them into navigable documentation, with customizable templates to tailor the for needs. JSDoc offers extensibility through the creation of custom tags and templates, enabling users to define project-specific documentation elements via plugins or files. For instance, developers can implement new tags to handle domain-specific annotations, and modify output templates to integrate with various publishing systems, ensuring adaptability to diverse workflows. The tool maintains compatibility with modern standards, including ES6 and later features such as classes, modules, async functions, and generics, allowing seamless of contemporary code patterns without requiring adjustments. Furthermore, JSDoc integrates effectively with environments, where its type annotations can be used in JavaScript files to leverage TypeScript's type checking and IntelliSense while generating that aligns with TypeScript's , supporting hybrid projects that mix typed and untyped code.

History and Development

Origins and Early Versions

JSDoc's development began with JSDoc.pm, a simple Perl-based system created by Michael Mathews in 2001. The project evolved with the release of JsDoc Toolkit () in , drawing inspiration from JavaDoc's approach to generating documentation from code comments. This iteration addressed the challenges of documenting dynamically typed languages like , where built-in type information and formal documentation were absent, allowing developers to embed structured comments directly in to produce readable HTML outputs. The modern incarnation, JSDoc 3, saw its initial release in 2011, licensed under the 2.0, which facilitated broader adoption by permitting both commercial and non-commercial use while ensuring compatibility with open-source practices. Primarily motivated by the need to provide maintainable documentation for growing applications, particularly in server-side environments, it emphasized simplicity in comment-based over complex tooling. Early adoption was prominent within the community, where JSDoc proved valuable for documenting modules and APIs in backend projects, helping standardize documentation amid the rapid expansion of server-side in the early . Around , the project transitioned to a fully community-driven effort on , with key early contributors who enhanced and template features, solidifying its role as a collaborative open-source initiative. This shift marked a pivotal point, enabling ongoing improvements while maintaining Mathews' foundational vision, before major evolutions in later versions.

Major Releases and Evolution

JSDoc 3.0.0 marked a significant when it was released in May 2012, introducing a robust template system that enabled developers to customize output formats and layouts, moving beyond the rigid structures of earlier versions. This release laid the foundation for modern JSDoc by supporting inline parsing and generating HTML-based references, fostering greater adoption in projects. Subsequent updates in the 3.x series enhanced language feature support, with version 3.4.0 in November 2015 adding parsing for ES2015 classes and modules, including initial JSX handling, which improved compatibility with emerging standards. Version 3.5.0, released in July 2017, integrated the parser to provide comprehensive ES2015+ support, including async/await and generator functions, along with new tags like @async and @generator to better document asynchronous code patterns. These changes addressed key pain points in documenting modern , boosting JSDoc's utility in environments requiring Node.js 4.2.0 or later. Version 3.6.0, released in May 2019, further refined these capabilities with enhanced ES2015 class documentation and compatibility for Closure Compiler annotations, enabling stricter typing similar to through tags like @typedef and @enum for more precise type expressions. This update also introduced configuration options like templates.useShortNamesInLinks for cleaner output and improved plugin extensibility, making JSDoc more adaptable for large-scale projects. By 2020, these enhancements solidified JSDoc's role in hybrid / workflows, where developers could leverage TypeScript-like type annotations without full compilation. The transition to JSDoc 4.0.0 in November 2022 represented a major evolutionary step, adopting semantic versioning to standardize release cycles and dependency management, while removing the legacy taffydb for better performance and requiring Node.js 12.0.0 or later. This version emphasized modularity and efficiency in the plugin ecosystem, allowing easier extension for custom parsers and themes. As of November 2025, the latest stable release is 4.0.5 from October 2025, which includes bug fixes for compatibility with Node.js 23 and optimizations in parsing speed, contributing to broader adoption in performance-sensitive applications. Throughout its evolution, JSDoc has benefited from active community involvement on , where numerous pull requests have driven features like advanced type handling and runtime integrations. Community efforts have extended JSDoc to modern runtimes, including experimental support for Deno and through custom configurations and plugins that adapt its Node.js-based parsing to these environments.

Syntax Fundamentals

Comment Structure

JSDoc documentation comments are exclusively block comments that begin with the sequence /** and end with */, distinguishing them from standard multi-line comments starting with /* or single-line comments using //. The /** format ensures that the JSDoc parser recognizes and processes the comment for generating documentation, whereas // comments are treated as ordinary inline annotations without structured parsing support in JSDoc. The required structure of a JSDoc comment starts with the opening /**, followed by optional leading asterisks on subsequent lines for readability, a descriptive text block that provides an overview of the documented symbol, and then optional block tags prefixed with @ on separate lines. The descriptive text precedes any tags and can span multiple lines, while the closing */ must appear on its own line after all content. This format allows for a where the main description sets the context, and tags add without interrupting the narrative flow. Placement conventions dictate that JSDoc comments must appear immediately preceding the code symbol they document, such as a declaration, definition, assignment, or in an object literal, to associate the documentation correctly during parsing. For instance, the comment block should have no intervening code or whitespace between it and the target symbol, ensuring unambiguous linking in the generated output. Nesting rules permit JSDoc comments within complex structures like classes or objects, where individual comments can document inner members such as methods or properties by placing a /** block directly before each one. This approach supports hierarchical documentation without requiring a single encompassing comment for the entire structure, though outer comments can provide overarching descriptions while inner ones focus on specifics. Avoid using sequences like */ in descriptions, as they will prematurely terminate the comment. For curly braces in inline tags embedded within the text, a closing brace (}) must be escaped as \{ to include it verbatim. Asterisks (*) can generally appear literally in descriptive text as long as they do not form tag delimiters. Avoid starting lines with @ for literal text outside of tags, as it may be parsed as a block tag; use indentation, spaces before @, or restructure the text to avoid issues. The following example illustrates the basic structure and placement for a , with descriptive text and optional lines: 
/**
 * This [function](/page/Function) processes input [data](/page/Data).
 * It handles validation and transformation.
 *
 * @param {string} input - The [data](/page/Data) to process.
 * @returns {[boolean](/page/Boolean)} Success indicator.
 */
[function](/page/Function) processData(input) {
  // [Implementation](/page/Implementation) here
}
```[](https://jsdoc.app/about-getting-started)

### Basic Tag Syntax

JSDoc [tags](/page/Tag) provide structured [metadata](/page/Metadata) within [documentation](/page/Documentation) comments, following a consistent syntax to ensure reliable [parsing](/page/Parsing) and generation of [documentation](/page/Documentation). The basic format for a block [tag](/page/Tag) is `@tagname [optional description or parameters]`, where the tag name begins with an `@` symbol, optionally followed by type information, identifiers, and a descriptive text separated by a [hyphen](/page/Hyphen) or [space](/page/Space). This structure allows [tags](/page/Tag) to annotate elements like [functions](/page/Function), parameters, or returns, with the [description](/page/Description) providing additional context about usage or behavior.[](https://jsdoc.app/about-block-inline-tags)

Type expressions in JSDoc are enclosed in curly braces `{}` to denote the data type precisely, enhancing type checking and IDE support. For instance, simple types use `{string}` or `{number}`, while complex types employ notations like `{Array.<number>}` for arrays of numbers or `{Object.<string, boolean>}` for objects with string keys and boolean values. Inline tags, which embed annotations within descriptions, follow the pattern `{@tag value}`, such as `{@type string}` to specify a type mid-sentence. These curly brace conventions draw from Closure Compiler annotations, integrated into JSDoc since version 3.2, to support advanced type expressions including unions like `{(number|string)}`, nullable types `{?number}`, and non-nullable `{!number}`.[](https://jsdoc.app/tags-type)[](https://jsdoc.app/tags-type)

Multi-line tags are handled by continuing the description on subsequent lines within the comment block, without additional markers, while separate tags require line breaks after each `@tagname` declaration. For extended descriptions, the content flows naturally until the next tag or the block's end, allowing for detailed explanations without breaking the structure. If a tag spans multiple lines, JSDoc parses it as a single unit, preserving formatting for [readability](/page/Readability) in generated output.[](https://jsdoc.app/about-block-inline-tags)

While JSDoc supports legacy formats, such as `@param` without curly braces for types (e.g., `@param name - description`), this older syntax is discouraged as it omits type information, reducing the effectiveness of tools like static analyzers and [IDE](/page/IDE) autocompletion. Modern practice mandates including types in braces for parameters and similar tags to leverage full [type inference](/page/Type_inference) capabilities.[](https://jsdoc.app/tags-param)

Malformed tags, such as unclosed curly braces or invalid type expressions, trigger [parsing](/page/Parsing) errors during JSDoc processing, potentially halting [documentation](/page/Documentation) generation or producing incomplete output. To mitigate this, the `--lenient` command-line option downgrades type-related errors to warnings, allowing [parsing](/page/Parsing) to continue while flagging issues for correction. Proper syntax adherence ensures robust handling across parsers and integrations.[](https://jsdoc.app/tags-type)

## Core Tags and Annotations

### Parameter and Return Tags

The `@param` [tag](/page/Tag) is used to document the [parameter](/page/Parameter)s of a [function](/page/Function), specifying the name, type, and description for each input argument. Its basic syntax is `@param {type} parameterName - description`, where the type is enclosed in curly braces and is optional, the parameter name is required, and the description follows a [hyphen](/page/Hyphen) for readability.[](https://jsdoc.app/tags-param) This [tag](/page/Tag) supports aliases such as `@arg` and `@argument`, which [function](/page/Function) identically to `@param`.[](https://jsdoc.app/tags-param)

For optional parameters, the name can be enclosed in square brackets, as in `@param {string} [optionalName] - An optional string value`, indicating the argument can be omitted. Default values are documented by including them within the brackets, for example, `@param {number} [count=1] - Number of items, defaults to 1`. Variadic parameters, representing rest arguments, are denoted with ellipsis notation like `@param {...string} items - Variable number of string items`. Union types for parameters that accept multiple possible types are expressed using the pipe operator, such as `@param {string|number} value - A value that can be a string or number`; these type expressions follow the syntax detailed in the type documentation.[](https://jsdoc.app/tags-param)

The `@returns` tag documents the value returned by a function, with the syntax `@returns {type} description`, where the type is optional and the description provides context about the output. It accepts aliases like `@return`, which behaves the same way. For functions that return nothing, the type can be omitted or specified as `{void}`; asynchronous functions commonly use `@returns {Promise<type>}` to indicate a promised result, such as `@returns {Promise<string>} A resolved string value`. Union types are also supported here, e.g., `@returns {number|string} Either a number or string`.[](https://jsdoc.app/tags-returns)

These tags are particularly valuable for documenting overloaded functions, where multiple sets of `@param` and `@returns` tags describe each possible signature, enabling clear [API](/page/API) documentation for polymorphic behaviors. In asynchronous contexts, combining `@returns` with [Promise](/page/Promise) types ensures generated documentation reflects modern [JavaScript](/page/JavaScript) patterns like async/await.[](https://jsdoc.app/tags-param)[](https://jsdoc.app/tags-returns)

### Type and Property Tags

The [@type](/page/type) tag in JSDoc allows developers to specify the [data type](/page/Data_type) of a [variable](/page/Variable), [property](/page/Property), or return value, enhancing [code](/page/Code) readability and enabling tools like type checkers to infer types accurately.[](https://jsdoc.app/tags-type) This tag supports a wide range of type expressions, including primitives like `{string}` or `{number}`, as well as more complex constructs such as unions `{number|string}`, making it essential for documenting dynamic [JavaScript](/page/JavaScript) code in a type-safe manner.[](https://jsdoc.app/tags-type)

For object literals and interfaces, the @property tag (or its synonym @prop) documents individual members of an object, specifying their types and descriptions within the context of a [class](/page/Class), [namespace](/page/Namespace), or [typedef](/page/Typedef).[](https://jsdoc.app/tags-property) The syntax follows `@property {type} name - description`, where the type can reference primitives or custom definitions, and optional properties are denoted with square brackets, such as `@property {string} [nickname] - Optional user nickname`.[](https://jsdoc.app/tags-property) This tag is particularly useful for listing static properties without defining actual code, ensuring comprehensive documentation for object structures.[](https://jsdoc.app/tags-property)

To create reusable custom type aliases, the @typedef tag defines named types that can be referenced elsewhere, promoting consistency across documentation.[](https://jsdoc.app/tags-typedef) Its syntax is `@typedef {type} name`, as in `/** @typedef {(number|string)} NumberLike */`, which can then be used in other tags like `@type {NumberLike} value`.[](https://jsdoc.app/tags-typedef) Complex types defined via @typedef often incorporate @property for detailing object members, such as `/** @typedef {Object} User @property {string} name @property {number} age */`, allowing for intricate data models without redundant declarations.[](https://jsdoc.app/tags-typedef)

JSDoc's type system supports advanced expressions for common scenarios, including nullable types with `?` (e.g., `{?string}` for string or null), arrays via `[type]` or `Array.<type>` (e.g., `{string[]}`), and function types like `{function(string, number): boolean}` to describe signatures precisely.[](https://jsdoc.app/tags-type) These constructs, rooted in Google Closure Compiler compatibility, enable detailed type annotations such as record types `{Object.<string, boolean>}` for key-value mappings.[](https://jsdoc.app/tags-type)

For integrating with third-party libraries, the @external tag marks symbols from external sources, allowing their types to be referenced without full redefinition, such as `@external [String](/page/String)` followed by extensions like `@method {function(): string} [rot13](/page/ROT13)`.[](https://jsdoc.app/tags-external) This facilitates documentation of interactions with libraries like [jQuery](/page/JQuery) or browser APIs, using prefixes like `external:XMLHttpRequest` in links or inheritance tags.[](https://jsdoc.app/tags-external) Such types can be employed in @param tags for [function](/page/Function) arguments, as detailed in the Parameter and Return Tags section.[](https://jsdoc.app/tags-type)

## Advanced Usage

### Module and Namespace Tags

In large [JavaScript](/page/JavaScript) projects, [module](/page/Module) and [namespace](/page/Namespace) tags in JSDoc enable developers to organize and [document](/page/Documentation) code structures that group related symbols, facilitating better navigation and understanding in generated [documentation](/page/Documentation). These tags are particularly essential for modular architectures, where code is divided into self-contained units that [export](/page/Export) specific members while hiding [implementation](/page/Implementation) details. By declaring [modules](/page/Module) and namespaces explicitly, JSDoc can generate hierarchical [documentation](/page/Documentation) that reflects the project's organization, often using namepaths prefixed with "module:" for cross-references.[](https://jsdoc.app/tags-module)

The [@module](/page/Module) tag declares the current [file](/page/File) as a module, treating all symbols within it as module members unless overridden. Its syntax is `@module [[{<type>}] <moduleName>]`, where the optional type expression (such as `{Object}`) specifies the module's type, and the name identifies the module for referencing; in JSDoc 3.3.0 and later, the name can include a "module:" prefix. For example:
/** myModule */ 

This creates namepaths like `module:myModule~foo` for inner members or `module:myModule.bar` for outer ones. If no name is provided, JSDoc derives it from the file path, such as "test" for "test.js". The tag supports linking via `{@link module:moduleName}` and is foundational for documenting exports in various module systems.[](https://jsdoc.app/tags-module)

The @namespace tag documents an object that groups related functions, classes, or properties into a logical [namespace](/page/Namespace), or defines a virtual namespace for symbols used elsewhere in the code. Its syntax is `@namespace [[{<type>}] <namespaceName>]`, requiring a name if a type is specified; the type, if provided, must align with the symbol, such as `{Object}` for object literals. For instance:
/** @namespace / var MyNamespace = { /* @function foo */ foo: function() {}, bar: 1 }; 

Or for a virtual namespace:
/** @namespace MyNamespace / /* @function myFunction @memberof MyNamespace */ function myFunction() {} 

Namespaces with unusual characters in names, like "!", require double quotes and backslash-escaped quotes if needed. This tag promotes [code organization](/page/Organization) by allowing members to be documented with `@memberof` for inclusion under the namespace.[](https://jsdoc.app/tags-namespace)

The @exports tag specifies the member exported by a module, crucial when the export differs from the default "exports" object or "module.exports" property, such as in custom assignments or AMD patterns. Its syntax is `@exports <moduleName>`, optionally prefixed with "module:" in JSDoc 3.3.0 and later. An example in an AMD module:
/** @exports hello/world */ var ns = {}; return ns; 

JSDoc automatically detects standard CommonJS exports without this tag, but @exports ensures accurate documentation for non-standard cases, generating correct namepaths like `module:hello/world.property`.[](https://jsdoc.app/tags-exports)

The @fileoverview tag, synonymous with @file and @overview, provides an overall [description](/page/Description) for the entire [file](/page/File), typically placed at the beginning of the source [code](/page/Code). Its syntax is `@fileoverview [description]`, allowing additional tags like @author. For example:
/** 

This tag generates file-level summaries in [documentation](/page/Documentation), aiding in quick overviews of a module's purpose without delving into individual symbols.[](https://jsdoc.app/tags-file)

JSDoc handles different module patterns through these tags, adapting to CommonJS, ES modules, and UMD. For [CommonJS](/page/CommonJS) modules, @module identifies the file (e.g., `@module my/shirt` for `require('my/shirt')`), and @exports or @alias documents custom exports like local variables assigned to module.exports; JSDoc auto-detects properties on exports, module.exports, or this. In ES 2015 modules (supported since JSDoc 3.4.0), @module declares the module (e.g., `@module my/shirt` for `import * as myShirt from 'my/shirt'`), with exports documented directly on export statements—such as functions or constants—and namepaths like `module:my/shirt.Member`; imports can reference via `@see module:otherModule`. UMD patterns, which wrap code for multiple environments (e.g., browser globals, CommonJS, [AMD](/page/AMD)), are documented similarly by treating the wrapped export as a [global](/page/Global) or module via @exports on the return value, though this may require additional @global or verbose @memberof for full hierarchy; official support focuses on underlying patterns rather than UMD-specific syntax. Type expressions in these tags, like `{Object}` for namespaces, enhance precision by integrating with JSDoc's [type system](/page/Type_system).[](https://jsdoc.app/howto-commonjs-modules)[](https://jsdoc.app/howto-es2015-modules)[](https://jsdoc.app/tags-exports)

### Event and Callback Tags

JSDoc provides specialized tags to document asynchronous and [event-driven](/page/event-driven) patterns prevalent in [JavaScript](/page/JavaScript), such as custom events, emitted events, callbacks, and generator yields, enabling clearer documentation of concurrency behaviors in objects, classes, and functions. These tags facilitate the generation of structured [API](/page/API) references that describe how code handles events and asynchronous operations, which is essential for maintaining large-scale applications using event emitters or promises. By integrating these annotations, developers can specify event properties, callback signatures, and yielded values, improving code readability and tool integration without altering runtime logic.[](https://jsdoc.app/tags-event)[](https://jsdoc.app/tags-fires)[](https://jsdoc.app/tags-callback)

The [`@event`](/page/The_Event) tag documents custom events that can be emitted by objects or classes, typically represented as objects with specific [properties](/page/.properties). Its syntax is `@event <className>#[event:]<eventName>`, where the optional `event:` [namespace](/page/Namespace) is automatically prepended by JSDoc for linking purposes. For instance, in documenting a class method that handles a "[snowball](/page/Snowball)" event, one might specify [properties](/page/.properties) like `{[boolean](/page/Boolean)} isPacked` to describe the [event](/page/Event) [payload](/page/Payload). This tag pairs with `@fires` to indicate emission points and `@listens` for handlers, allowing comprehensive event lifecycle documentation; unlike earlier versions, JSDoc 3 focuses on event [content](/page/Content) rather than handler functions.[](https://jsdoc.app/tags-event)

To indicate that a method emits a particular event, the `@fires` tag (synonymous with `@emits`) is used with the syntax `@fires <className>#[event:]<eventName>`. This tag signals potential event triggers during method execution, and the event's details should be elaborated using `@event`. An example in a `Milkshake` class might annotate the `drink` method as follows:
/**
  • Drink the .
  • @fires Milkshake#drain */ Milkshake.prototype.drink = function() { // ... };

This ensures generated documentation highlights event flows, aiding in tracing asynchronous interactions.[](https://jsdoc.app/tags-fires)

For symbols that respond to events, the `@listens` tag specifies the event with syntax `@listens <eventName>`, often in the context of modules or methods. It complements `@event` by documenting listeners, such as a monitoring function that reacts to a "snowball" event with a `velocity` property of type `number`. In modular code, this might appear as:
/**
  • @listens module:hurler~event:snowball */ module.exports.reportThrowage = function() { // Handle event };

This tag supports event-driven architectures by clarifying dependencies on emitted signals.[](https://jsdoc.app/tags-listens)

Callback functions, common in asynchronous [APIs](/page/Apis), are documented using the `@callback` tag with syntax `@callback <namepath>`, which defines the function's parameters and [return](/page/Return) [value](/page/Value) akin to `@method`. It acts as a reusable type alias, suitable for class-specific (e.g., `Requester~requestCallback`) or global definitions. Parameters can include types like `{number} responseCode` and `{[string](/page/String)} responseMessage`, enabling precise specification of expected callback interfaces. This tag is particularly useful when callbacks are passed as arguments, promoting consistent [documentation](/page/Documentation) across functions.[](https://jsdoc.app/tags-callback)

JSDoc supports Promise-based asynchronous code through the `@async` tag, which marks functions declared with `async` syntax, indicating they return a `Promise`. With syntax `@async`, it is generally auto-detected by JSDoc but required for virtual comments; for return types, it integrates with `@returns` to specify resolved values like `Promise<string>`. For generator functions, the `@yields` tag (synonymous with `@yield`) documents yielded values using syntax `@yields [{type}] [description]`, available since JSDoc 3.5.0. An example for a Fibonacci generator:
/**
  • @yields {number} The next number in the Fibonacci sequence. / function fibonacci() { // ... }

This provides targeted annotation for iterative asynchronous patterns without overlapping basic return documentation.[](https://jsdoc.app/tags-async)[](https://jsdoc.app/tags-yields)

## Examples and Applications

### Documenting Functions

Documenting functions in JSDoc involves adding a block comment immediately before the function declaration, using tags to specify parameters, return values, exceptions, and usage examples. This approach enables tools to generate structured documentation and provides type hints for editors supporting JSDoc, such as [Visual Studio Code](/page/Visual_Studio_Code) or WebStorm.[](https://jsdoc.app/about-getting-started) The core tags for functions build on [basic](/page/Basic) syntax, focusing on clarity for parameters and outputs to aid code maintainability.[](https://jsdoc.app/tags-param)

A simple synchronous [function](/page/Function) can be documented using the `@param` tag for inputs, `@returns` for the output, and `@example` for usage illustration. The `@param` tag specifies the [parameter](/page/Parameter) name, type (optional), and description, following the syntax `@param {type} name - description`. For instance, consider a [function](/page/Function) that concatenates two [string](/page/String)s:

```javascript
/**
 * Concatenates two strings.
 * @param {string} first - The first string.
 * @param {string} second - The second string to append.
 * @returns {string} The concatenated result.
 * @example
 * const result = concatenate('Hello, ', 'world!');
 * // Returns 'Hello, world!'
 */
[function](/page/Function) concatenate(first, second) {
    return first + second;
}
This example highlights how @returns {type} description documents the function's output, while @example displays the provided code snippet as highlighted text in generated . Multiple @example tags can be used if needed, and captions can be added via <caption> for context. Optional parameters are denoted in @param with square brackets around the name, such as @param {string} [optionalParam], or by specifying a default value like @param {string= 'default'} name. The @throws tag documents potential errors, using syntax @throws {type} description or simply @throws description for free-form text; multiple instances are permitted for different conditions. For example: 
javascript
/**
 * Divides two numbers, throwing on invalid input.
 * @param {number} dividend - The number to divide.
 * @param {number} [divisor=1] - The divisor; defaults to 1.
 * @returns {number} The quotient.
 * @throws {Error} If divisor is zero.
 * @example
 * divide(10, 2); // Returns 5
 */
function divide(dividend, divisor = 1) {
    if (divisor === 0) {
        throw new Error('Division by zero');
    }
    return dividend / divisor;
}
Here, the optional divisor uses a default, and @throws alerts developers to runtime exceptions. Functions supporting overloads—multiple signatures for the same name—are documented by providing separate blocks of @param and @returns tags within the comment, separated by blank lines to delineate signatures. This allows tools to infer variants based on argument types or counts: 
javascript
/**
 * Adds two numbers or concatenates two [string](/page/String)s.
 *
 * @param {number} a - First number.
 * @param {number} b - Second number.
 * @returns {number} Sum of a and b.
 *
 * @param {[string](/page/String)} a - First [string](/page/String).
 * @param {[string](/page/String)} b - Second [string](/page/String).
 * @returns {[string](/page/String)} Concatenated strings.
 * @example
 * add(1, 2); // Returns 3
 * add('Hello', ' world'); // Returns 'Hello world'
 */
function add(a, b) {
    return typeof a === 'number' ? a + b : a + b;
}
This method ensures each overload is clearly described without a dedicated @overload tag, which is more common in TypeScript extensions. Inline examples within descriptions use the {@code} inline tag for code snippets, such as "Use {@code myFunc(arg)} to call the function," which renders as formatted code in output. Markdown formatting, like backticks for inline code, is also supported in descriptions for readability. Common pitfalls include mismatched types between JSDoc annotations and actual signatures, which can trigger warnings in inspections or type checkers, leading to unreliable or error detection. For instance, declaring @param {number} x when the function accepts a causes signature mismatches. Additionally, placing multiple documentation blocks before a function results in only the last one being parsed, ignoring prior comments like TODO notes; consolidate them into a single /** block. Section separators using **** in comments may be misinterpreted as documentation starters, so use plain /* */ instead.

Documenting Classes and Modules

JSDoc supports the documentation of classes through tags that describe constructors, s, and properties, enabling clear descriptions for object-oriented code. For ES2015 classes, JSDoc automatically recognizes class declarations and expressions, parsing them without requiring explicit tags like @class or @constructor, though these can be added for additional clarity. Instance s are documented using @method, and properties with @instance to specify they belong to class instances. Consider a basic class example representing a point in a plane: 
javascript
/**
 * Class representing a point.
 * @class
 */
class Point {
    /**
     * Create a point.
     * @constructor
     * @param {number} x - The x value.
     * @param {number} y - The y value.
     */
    constructor(x, y) {
        this.x = x;
        this.y = y;
    }

    /**
     * Get the x coordinate.
     * @method
     * @instance
     * @return {number} The x value.
     */
    getX() {
        return this.x;
    }

    /**
     * Get the y coordinate.
     * @method
     * @instance
     * @return {number} The y value.
     */
    getY() {
        return this.y;
    }
}
This structure documents the class overview, constructor parameters, and instance methods, generating output that distinguishes between the class as a whole and its members. Static methods are indicated with the @static tag, marking them as accessible on the class itself without instantiation, while inheritance is documented using @extends to link a subclass to its parent. For instance, extending the Point class to create a Dot subclass: 
javascript
/**
 * Class representing a dot.
 * @extends Point
 */
class Dot extends Point {
    /**
     * Create a dot.
     * @constructor
     * @param {number} x - The x value.
     * @param {number} y - The y value.
     * @param {number} width - The width of the dot, in pixels.
     */
    constructor(x, y, width) {
        super(x, y);
        this.width = width;
    }

    /**
     * Get the dot's width.
     * @method
     * @instance
     * @return {number} The dot's width, in pixels.
     */
    getWidth() {
        return this.width;
    }
}

/**
 * Convert a string to a Dot instance.
 * @static
 * @param {string} str - Comma-separated values for x, y, width.
 * @return {Dot} A new Dot object.
 */
Dot.fromString = function(str) {
    const [x, y, width] = str.split(',').map(Number);
    return new Dot(x, y, width);
};
The @extends tag ensures the subclass documentation reflects inherited members, and @static applies to class-level functions like factory methods. Modules in Node.js environments are documented using the @module tag to define the module scope, with classes exported via module.exports or similar patterns. The @classdesc tag provides a dedicated description for the class, separate from the constructor's documentation, which is particularly useful in modular exports. An example of a module exporting a class: 
javascript
/**
 * Module for color utilities.
 * @module color/mixer
 */

/**
 * A color [mixer](/page/Mixer) [class](/page/Class).
 * @class
 * @classdesc Mixes primary colors to create new shades.
 */
function ColorMixer() {
    /**
     * Blend two colors.
     * @constructor
     * @param {string} color1 - First color.
     * @param {string} color2 - Second color.
     * @return {string} Blended color.
     */
    this.blend = function(color1, color2) {
        // Implementation
        return 'blended';
    };
}

module.exports = ColorMixer;
Here, @module sets the namespace for exported symbols, and @classdesc offers a high-level summary. Private members in classes are marked with the @private tag, indicating they are intended for internal use only and are typically excluded from generated documentation unless explicitly included via command-line options. Access levels can be further specified with @access, supporting values like private, protected, public, or package to control visibility in object-oriented designs. For example, within a class: 
javascript
/**
 * A secure vault class.
 * @class
 */
class Vault {
    /**
     * @private
     * @access private
     */
    _secretKey = 'hidden';

    /**
     * Retrieve data (protected accessor).
     * @method
     * @access protected
     * @return {string} Data.
     */
    getData() {
        return this._secretKey;
    }
}
The @private tag hides _secretKey by default, while @access protected limits getData to subclasses or internal code. A real-world snippet from a Node.js module, such as a bookshelf utility, illustrates combined usage in CommonJS: 
javascript
/**
 * Module for bookshelf-related utilities.
 * @module bookshelf
 */

/**
 * Create a new Book.
 * @class
 * @classdesc Represents a book in a library system.
 * @param {string} title - The title of the book.
 */
this.Book = function(title) {
    /**
     * The title of the book.
     * @instance
     * @private
     */
    this.title = title;

    /**
     * Get book title.
     * @method
     * @access public
     * @return {string} Title.
     */
    this.getTitle = function() {
        return this.title;
    };
};

module.exports = this;
This exports a constructor function as a class, using @module for the file scope, @classdesc for overview, @instance and @private for the property, and @access for the method.

Integration and Tools

Editor Support

JSDoc annotations enable robust editor support by allowing integrated development environments () to parse comments and provide features like autocompletion, type hints, and error detection during coding. This integration transforms plain into a more type-aware experience without requiring a full switch to , enhancing developer productivity through real-time feedback. In (VS Code), JSDoc is natively supported through built-in parsing that powers IntelliSense, offering intelligent , parameter information, and hover tooltips based on annotations like @param and @type. For instance, typing a with JSDoc comments triggers suggestions for types and values, reducing errors and speeding up development. This feature leverages the language service under the hood to interpret JSDoc in JavaScript files. WebStorm and other IDEs provide comprehensive JSDoc support, including type hints derived from @type annotations to display parameter details and inferred return types inline. These IDEs also generate JSDoc stubs automatically when typing /** above functions, and they validate comment structures for consistency, such as ensuring required tags are present. This setup is particularly useful for large codebases where improves navigation and refactoring. For projects mixing and , JSDoc serves as a fallback mechanism, allowing TypeScript's compiler and tools to check .js files annotated with JSDoc comments via a jsconfig.json . This enables type checking, autocompletion, and error highlighting in editors like VS Code for untyped , bridging the gap between dynamic and static typing without renaming files. Supported constructs include interfaces, generics, and unions, making it viable for gradual adoption. JSDoc validation during development is further enhanced by integration, particularly through the @typescript-eslint plugin, which extends linting to parse and enforce JSDoc comments in JavaScript files for type-aware rules. When combined with eslint-plugin-jsdoc, it checks for complete tags, valid types compatible with or Compiler, and consistent formatting, flagging issues like missing @param descriptions or invalid @type expressions. This setup requires configuring to use the TypeScript parser for JS files, ensuring annotations contribute to overall code quality checks. AI-powered tools incorporate JSDoc-aware suggestions to streamline documentation. In editors like Cursor, the built-in docstring generator auto-produces comments for functions, inferring types from context and code patterns to maintain consistency. Similarly, in VS Code leverages JSDoc annotations to refine its code completions, suggesting annotated functions with accurate parameter hints and even generating missing JSDoc blocks based on function signatures, making it a complementary tool for annotated workflows.

Build and Generation Tools

JSDoc provides a (CLI) for generating documentation from annotated , primarily producing static output by default. The core command is jsdoc, which processes JavaScript files specified as arguments or via a ; for instance, jsdoc -c conf.json loads settings from a or JavaScript to define input sources, output directories, and other options like -d for the destination path or -a to include private members. This CLI supports extensibility through plugins and templates, enabling customized workflows in build pipelines. Templates in JSDoc control the visual and structural presentation of the generated . The template, known as "," renders a multi-page site with navigation, search, and syntax-highlighted code examples, configurable via options such as default.includeDate for timestamps or default.outputSourceFiles for source listings. templates like Minami, a minimalist single-page , or Docdash, a responsive theme inspired by , can be installed via and specified in the configuration's templates property to override the default styling and layout. These templates are often community-maintained and focus on readability for large . Integration with build tools streamlines documentation generation during development and deployment. In npm projects, JSDoc is commonly added to package.json scripts, such as "docs": "jsdoc -c jsdoc.json", allowing execution via npm run docs for automated builds. For bundlers like , the jsdoc-webpack-plugin hooks into the compilation process, running JSDoc on bundled outputs post-build to generate docs without separate CLI invocations, configurable with options like source inclusion patterns. As an alternative for TypeScript-heavy projects, TypeDoc serves as a that supports a subset of JSDoc annotations alongside native types, producing similar HTML outputs but with enhanced and module resolution tailored to .ts files. This makes TypeDoc suitable for mixed JavaScript/ codebases where full adoption is partial. JSDoc's output formats extend beyond through plugins and integrations. The built-in Markdown plugin converts inline in comments to during generation, while tools like swagger-jsdoc parse JSDoc tags to produce OpenAPI-compliant specifications for documentation, integrable with . Additional plugins enable exports of the parsed for programmatic use in custom tools.

Standards and Best Practices

Coding Conventions

Coding conventions for JSDoc emphasize consistency, readability, and completeness to ensure documentation remains maintainable across projects and teams. Major style guides, such as Google's Style Guide, mandate JSDoc for public , requiring documentation for all classes, methods, and functions to facilitate code validation and comprehension. In contrast, the Style Guide prioritizes structured multiline comments using /** ... */ blocks, which serve as the foundation for JSDoc adoption without specifying mandatory tags. These conventions promote using JSDoc to annotate public-facing code, focusing on essential tags like @param, @returns, and @type to describe parameters, returns, and types explicitly. Descriptions in JSDoc should be written in complete sentences, starting with a for methods (e.g., "Calculates the sum of two numbers") to provide clear, actionable information. JSDoc supports markup for formatting, such as bold or italic text, and can be extended with a plugin to enable richer elements like lists and within descriptions. For cross-references, the {@link} inline allows linking to other symbols or URLs, with optional text (e.g., {@link module:utils.add|add [function](/page/Function)}), enhancing without disrupting the . Type annotations in JSDoc prioritize native JavaScript types (e.g., {string}, {number}, {boolean}) for simplicity and interoperability, resorting to custom types via @typedef only when native ones are insufficient for complex structures. This approach ensures consistency, as seen in Google's guidelines, which require braces around types and modifiers like ? for optional or nullable values (e.g., {?string}), avoiding overly verbose custom definitions unless necessary for domain-specific logic. To track evolution, the @since tag specifies the version or date when a symbol was introduced (e.g., @since 1.2.0), aiding users in understanding stability. Conversely, the @deprecated tag marks outdated s, optionally including migration guidance (e.g., @deprecated Use newMethod instead), which is required in style for any phased-out public APIs. For team-wide consistency, projects can define conventions in a .jsdoc.[json](/page/JSON) configuration file, specifying options like enabled tags, templates, and support to enforce standards during generation. This file, passed via the -c command-line option, allows customization without altering individual comments, promoting uniform adoption across collaborators.

Common Challenges and Solutions

One common challenge in JSDoc usage arises from parsing errors when dealing with complex type expressions, such as intricate union types or regex patterns in tags like @type or @pattern, which can cause the parser to fail or produce incomplete . To address this, developers can simplify type expressions by breaking them into smaller, more manageable components or use the @ignore tag to exclude problematic symbols entirely from the generated output, ensuring the rest of the documentation proceeds without interruption. Another frequent issue involves incompatibilities with minifiers, where tools like Terser strip out JSDoc comments during the minification process, potentially removing valuable from production bundles. Solutions include configuring the minifier to preserve specific comments via its --comments option with a that matches JSDoc blocks (e.g., /^/**/), or integrating plugins like terser-webpack-plugin that support comment retention for and purposes. Maintaining consistent JSDoc documentation across large codebases often proves difficult due to varying developer adherence and the volume of files involved. via pre-commit hooks, such as those implemented with the pre-commit framework combined with the eslint-plugin-jsdoc, can enforce JSDoc requirements by linting staged files before commits, flagging missing or invalid annotations to promote uniformity without manual oversight. As of 2025, a notable gap persists in fully supporting JSX and TSX documentation without integrating , as JSDoc's native parser struggles with JSX syntax in comments, leading to incomplete for components. Workarounds include using JSDoc's @type tag to explicitly annotate JSX elements as React.Element or similar, and configuring editors like VS Code with checkJs enabled to leverage partial type checking, though this falls short of TypeScript's comprehensive JSX handling. Performance bottlenecks during JSDoc generation, particularly in expansive projects, can result in lengthy build times due to full parsing on each run. Optimizations involve omitting the --private command-line flag (default behavior) to exclude members, thereby reducing the number of parsed symbols, alongside external caching strategies like incremental tools or template-based regeneration to avoid reprocessing unchanged files.

References

  1. [1]
    Use JSDoc: Getting Started with JSDoc 3
    ### Summary of JSDoc from https://jsdoc.app/about-getting-started
  2. [2]
    jsdoc/jsdoc: An API documentation generator for JavaScript. - GitHub
    The JSDoc community has created templates and other tools to help you generate and customize your documentation. Here are a few of them.
  3. [3]
    jsdoc - NPM
    Oct 8, 2025 · An API documentation generator for JavaScript.. Latest version: 4.0.5, last published: a month ago. Start using jsdoc in your project by ...
  4. [4]
    JSDoc Reference - TypeScript: Documentation
    The list below outlines which constructs are currently supported when using JSDoc annotations to provide type information in JavaScript files.
  5. [5]
    JavaScript in Visual Studio Code
    JSDoc support. VS Code understands many standard JSDoc annotations, and uses these annotations to provide rich IntelliSense. You can optionally even use the ...Missing: analysis | Show results with:analysis<|control11|><|separator|>
  6. [6]
    Leveraging JSDoc for Better Code Documentation in JavaScript
    Apr 4, 2024 · For further exploration, the official JSDoc website offers comprehensive guides and the full list of supported tags, providing everything ...<|control11|><|separator|>
  7. [7]
    Annotating JavaScript for the Closure Compiler - GitHub
    May 4, 2021 · This document describes the set of annotations and type expressions that the Closure Compiler understands. This table includes only tags that ...
  8. [8]
    JSDoc: Tags: @type
    The @type tag allows you to provide a type expression identifying the type of value that a symbol may contain, or the type of value returned by a function.
  9. [9]
    Configuring JSDoc with a configuration file
    source.include : An optional array of paths that contain files for which JSDoc should generate documentation. The paths given to JSDoc on the command line are ...
  10. [10]
    About JSDoc plugins
    As of version 3.5.0, JSDoc uses the current version of the Babylon parser with all plugins enabled. e : The event. If the node is one that the parser ...
  11. [11]
    Use JSDoc: ES 2015 Modules
    Module identifiers. When you document an ES 2015 module, you'll use a @module tag to document the identifier for the module. For example, if users load the ...
  12. [12]
    jsdoc - npm
    for use under the X11/MIT License. JsDoc Toolkit is Copyright (c)2009 Michael Mathews <micmath@gmail.com> Additional portions are Copyright (c)2010 Aaron ...
  13. [13]
    Using JSDoc-Toolkit for other languages - Google Groups
    Jan 17, 2021 · Is it possible to configure that, too? Kind regards, Jan.. Michael Mathews's profile photo. Michael Mathews. unread,. Dec 26, 2009, 3:21:01 PM12/26/09.documenting dynamic methods - Google GroupsHow do I jsdoc a script that has functions that have functions.More results from groups.google.com
  14. [14]
    Use JSDoc: CommonJS Modules
    This page explains how to document CommonJS and Node.js modules that use several different coding conventions.
  15. [15]
    https://raw.githubusercontent.com/jsdoc/jsdoc/main/CHANGES.md
  16. [16]
    None
    ### Summary of Key JSDoc Changes (3.0 to Latest)
  17. [17]
    Properly integrating JSDoc and type definitions for Deno and JSR
    Nov 28, 2024 · I'm working on a JavaScript codebase designed for both Deno and browsers. We're adding documentation and types to publish it on JSR, but I've hit some ...Missing: forks Bun
  18. [18]
    Use JSDoc: Block and inline tags
    Block tags, which are at the top level of a JSDoc comment. · Inline tags, which are within the text of a block tag or a description.Missing: structure | Show results with:structure
  19. [19]
    prop / property - Use JSDoc
    The @property tag is a way to easily document a list of static properties of a class, namespace or other object.Missing: structure | Show results with:structure
  20. [20]
    param tag - Use JSDoc
    The @param tag provides the name, type, and description of a function parameter. The @param tag requires you to specify the name of the parameter you are ...
  21. [21]
    returns tag - Use JSDoc
    The @returns tag documents the value that a function returns. If you are documenting a generator function, use the @yields tag instead of this tag.<|control11|><|separator|>
  22. [22]
    typedef tag - Use JSDoc
    The @typedef tag is useful for documenting custom types, particularly if you wish to refer to them repeatedly. These types can then be used within other tags ...<|separator|>
  23. [23]
    external tag - Use JSDoc
    The `@external` tag identifies a class, namespace, or module defined outside the current package, and should be applied to the highest-level symbol.
  24. [24]
    module tag - Use JSDoc
    The @module tag marks the current file as being its own module. All symbols in the file are assumed to be members of the module unless documented otherwise.
  25. [25]
    namespace - Use JSDoc
    If the symbol's name already contains one or more double quotes, escape the double quotes with a leading backslash (\). Using the @namespace tag with unusual ...Missing: special | Show results with:special
  26. [26]
    exports tag - Use JSDoc
    Use the @exports tag when documenting JavaScript modules that export anything other than the "exports" object or the "module.exports" property.
  27. [27]
    file tag - Use JSDoc
    The @file tag provides a description for a file. Use the tag in a JSDoc comment at the beginning of the file.
  28. [28]
    event tag - Use JSDoc
    The @event tag allows you to document an event that can be fired. A typical event is represented by an object with a defined set of properties.<|control11|><|separator|>
  29. [29]
    fires - Use JSDoc
    The @fires tag indicates that a method can fire a specified type of event when it is called. Use the @event tag to document the event's content. Examples.
  30. [30]
    callback tag - Use JSDoc
    The @callback tag provides information about a callback function that can be passed to other functions, including the callback's parameters and return value.
  31. [31]
    listens - Use JSDoc
    The @listens tag indicates that a symbol listens for the specified event. Use the @event tag to document the event's content.<|control11|><|separator|>
  32. [32]
    async tag - Use JSDoc
    This tag is available in JSDoc 3.5.0 and later. In general, you do not need to use this tag, because JSDoc automatically detects asynchronous functions and ...Missing: 3.6 2020 TypeScript
  33. [33]
    yields tag - Use JSDoc
    The @yields tag documents the value that is yielded by a generator function. This tag is available in JSDoc 3.5.0 and later.
  34. [34]
    Examples - Use JSDoc
    The `@example` tag shows highlighted code as an example of a documented item. It can be captioned using `<caption></caption>` after the tag.
  35. [35]
    Use JSDoc
    ### @throws Tag Summary
  36. [36]
    Document overloaded function in JSDoc - javascript - Stack Overflow
    Mar 27, 2018 · I have an overloaded toggle function and want to document the behaviors w/ JSDoc. If the value is defined the window state is set to the boolean ...JSDoc: where to put overloaded function description - Stack OverflowJSDoc overloaded function not working with TypeScriptMore results from stackoverflow.com
  37. [37]
    Mismatched JSDoc and function signature | Inspectopedia - JetBrains
    Sep 18, 2025 · Signature mismatch · Syntax errors and unresolved references in JSDoc · Type mismatch · Unfiltered for..in loop · Unnecessary semicolon ...Missing: common | Show results with:common
  38. [38]
    https://dev.to/fedtti/why-github-copilot-and-jsdoc-are-a-dynamic-duo-on-vs-code-4dbk
  39. [39]
    Use JSDoc: ES 2015 Classes
    Documenting a simple class. The following example shows how to document a simple class with a constructor, two instance methods, and one static method:.
  40. [40]
    static - Use JSDoc
    The @static tag indicates that a symbol is contained within a parent and can be accessed without instantiating the parent.
  41. [41]
    augments (or @extends ) tag - Use JSDoc
    The @augments or @extends tag indicates that a symbol inherits from, and potentially adds to, a parent symbol. You can use this tag to document both class-based ...Missing: structure | Show results with:structure
  42. [42]
    classdesc - Use JSDoc
    The @classdesc tag is used to provide a description for a class, separate from the constructor function's description. Use the @classdesc tag in combination ...
  43. [43]
    private tag - Use JSDoc
    The @private tag marks a symbol as private, or not meant for general use. Private members are not shown in the generated output unless JSDoc is run with the -p ...
  44. [44]
    access <package|private|protected|public> - Use JSDoc
    The @access tag specifies the access level of a member. You can use the @access tag as a synonym for other tags.
  45. [45]
    Working with JavaScript - Visual Studio Code
    Visual Studio Code's JavaScript IntelliSense provides intelligent code completion, parameter info, references search, and many other advanced language features.IntelliSense · JavaScript projects (jsconfig... · Type checking JavaScript
  46. [46]
    JSDoc comments | WebStorm Documentation - JetBrains
    Aug 5, 2025 · Based on @type annotations, WebStorm shows parameter hints. Parameter hints are shown based on type annotations within JSDoc in a JavaScript ...
  47. [47]
    Documentation - JS Projects Utilizing TypeScript
    If you have a lot of JavaScript files you want to add errors to then you can switch to using a jsconfig.json . You can skip checking some files by adding a // @ ...<|separator|>
  48. [48]
    typescript-eslint/parser
    * Supported TypeScript versions: >=4.7.4 <5.7.0 * Your TypeScript version: 5.7.1. Please only submit bug reports when using the officially supported version.
  49. [49]
    gajus/eslint-plugin-jsdoc: JSDoc specific linting rules for ESLint.
    JSDoc specific linting rules for ESLint. Contribute to gajus/eslint-plugin-jsdoc development by creating an account on GitHub.<|control11|><|separator|>
  50. [50]
    Why GitHub Copilot and JSDoc Are a Dynamic Duo on VS Code
    Aug 22, 2025 · There were several unofficial JSDoc extensions for VS Code, but I do think that the built-in implementation is enough to get the best out of it.
  51. [51]
    Command-line arguments to JSDoc
    Only display symbols with the given access property: private , protected , public , or undefined , or all for all access levels. By default, all except private ...
  52. [52]
    Configuring JSDoc's default template
    JSDoc's default template provides several options that you can use to customize the appearance and content of generated documentation.
  53. [53]
    clenemt/docdash - Lodash inspired JSDoc 3 template/theme - GitHub
    A clean, responsive documentation template theme for JSDoc 4. docdash-screenshot docdash-screenshot-2 Example See http://clenemt.github.io/docdash/ for a ...Docdash · Sample Jsdoc. Json · Options
  54. [54]
    jsdoc-webpack-plugin - NPM
    Jan 29, 2020 · WebPack plugin that runs jsdoc on your bundles. Usage: In webpack.config.js: var webpack = require('webpack'); var JsDocPlugin = require('jsdoc-webpack-plugin' ...Missing: integration scripts
  55. [55]
    Using the Markdown plugin - JSDoc
    By default, the Markdown plugin does not hard-wrap text at line breaks. This is because it's normal for a JSDoc comment to be wrapped across multiple lines. If ...Missing: single | Show results with:single<|control11|><|separator|>
  56. [56]
    Surnet/swagger-jsdoc - GitHub
    This library reads your JSDoc-annotated source code and generates an OpenAPI (Swagger) specification.
  57. [57]
    Google JavaScript Style Guide
    9.1 JSDoc tag reference. JSDoc serves multiple purposes in JavaScript. In addition to being used to generate documentation it is also used to control tooling.
  58. [58]
    airbnb/javascript: JavaScript Style Guide - GitHub
    A mostly reasonable approach to JavaScript. Note: this guide assumes you are using Babel, and requires that you use babel-preset-airbnb or the equivalent.Missing: JSDoc | Show results with:JSDoc
  59. [59]
    description - Use JSDoc
    By using the @description tag, you can place the description anywhere in the JSDoc comment. Describing a symbol with the @description tag /** * @param {number} ...
  60. [60]
    {@link} inline tag - Use JSDoc
    The {@link} inline tag creates a link to the namepath or URL that you specify. When you use the {@link} tag, you can also provide link text, using one of ...Missing: single | Show results with:single
  61. [61]
    deprecated tag - Use JSDoc
    The @deprecated tag marks a symbol in your code as being deprecated. Examples. You can use the @deprecated tag by itself, or include some text that describes ...Missing: warnings | Show results with:warnings
  62. [62]
    JSDoc Parser breaks with a complex @pattern tag #18273 - GitHub
    Sep 6, 2017 · We should special case parsing of pattern tags to parse text till end of line instead of till next tag. PRs welcomed. sandersn ...
  63. [63]
    https://jsdoc.app/tags-ignore.html
  64. [64]
    Comments associated with discarded code are dropped · Issue #2500
    Nov 23, 2017 · A possible comprehensive solution in uglify would be to record all comments prior to the Compressor being run and tack all the orphaned/ ...
  65. [65]
    mishoo/UglifyJS: JavaScript parser / mangler / compressor ... - GitHub
    You can pass --comments to retain certain comments in the output. By default it will keep JSDoc-style comments that contain "@preserve", "@license" or ...Missing: plugin | Show results with:plugin
  66. [66]
    pre-commit
    You specify a list of hooks you want and pre-commit manages the installation and execution of any hook written in any language before every commit. pre-commit ...coursier · docker · rust · unsupported_script
  67. [67]
    Turning on JSDoc in VS Code produces "Cannot use JSX unless the
    Nov 25, 2020 · I am using JSDoc in this app to introduce type safety. Type safety is turned on using the following option in Visual Studio Code:How to use jsdoc with .tsx file - Stack OverflowReact and JSDoc - How to document a React component properly?More results from stackoverflow.comMissing: tag | Show results with:tag
  68. [68]
    Investigate making JSDoc parsing lazier and more optimal #52959
    Feb 24, 2023 · So there are a few things I want to investigate here: Can we optimize JSDoc parsing itself? Why is JSDoc parsing so slow in the first place?Missing: complex | Show results with:complex