eslint-plugin-jsdoc
JSDoc linting rules for ESLint.
Reference to jscs-jsdoc
This table maps the rules between eslint-plugin-jsdoc
and jscs-jsdoc
.
Installation
Install ESLint either locally or globally.
npm install eslint
If you have installed ESLint
globally, you have to install JSDoc plugin globally too. Otherwise, install it locally.
npm install eslint-plugin-jsdoc
Configuration
Add plugins
section and specify eslint-plugin-jsdoc
as a plugin.
{
"plugins": [
"jsdoc"
]
}
Finally, enable all of the rules that you would like to use.
{
"rules": {
"jsdoc/check-alignment": 1,
"jsdoc/check-examples": 1,
"jsdoc/check-indentation": 1,
"jsdoc/check-param-names": 1,
"jsdoc/check-syntax": 1,
"jsdoc/check-tag-names": 1,
"jsdoc/check-types": 1,
"jsdoc/implements-on-classes": 1,
"jsdoc/match-description": 1,
"jsdoc/newline-after-description": 1,
"jsdoc/no-types": 1,
"jsdoc/no-undefined-types": 1,
"jsdoc/require-description": 1,
"jsdoc/require-description-complete-sentence": 1,
"jsdoc/require-example": 1,
"jsdoc/require-hyphen-before-param-description": 1,
"jsdoc/require-jsdoc": 1,
"jsdoc/require-param": 1,
"jsdoc/require-param-description": 1,
"jsdoc/require-param-name": 1,
"jsdoc/require-param-type": 1,
"jsdoc/require-returns": 1,
"jsdoc/require-returns-check": 1,
"jsdoc/require-returns-description": 1,
"jsdoc/require-returns-type": 1,
"jsdoc/valid-types": 1
}
}
Settings
settings.jsdoc.allowPrivate
- Disables all rules for the comment block
on which it occurs.
Exempting empty functions from require-jsdoc
settings.jsdoc.exemptEmptyFunctions
- Will not report missing jsdoc blocks
above functions/methods with no parameters or return values (intended where
variable names are sufficient for themselves as documentation).
Alias Preference
Use settings.jsdoc.tagNamePreference
to configure a preferred alias name for a JSDoc tag. The format of the configuration is: <primary tag name>: <preferred alias name>
, e.g.
{
"rules": {},
"settings": {
"jsdoc": {
"tagNamePreference": {
"param": "arg",
"returns": "return"
}
}
}
}
This setting is utilized by the the rule for tag name checking
(check-tag-names
) as well as in the @param
and @require
rules:
check-param-names
check-tag-names
require-hyphen-before-param-description
require-description
require-param
require-param-description
require-param-name
require-param-type
require-returns
require-returns-check
require-returns-description
require-returns-type
Additional Tag Names
Use settings.jsdoc.additionalTagNames
to configure additional, allowed JSDoc
tags in the rule check-tag-names
. The format of the configuration is as follows:
{
"rules": {},
"settings": {
"jsdoc": {
"additionalTagNames": {
"customTags": ["define", "extends", "record"]
}
}
}
}
Allow @override
Without Accompanying @param
Tags
Use any of the following settings to override require-param
and allow
@param
to be omitted when the specified tags are present on the JSDoc
comment or the parent class comment. The default value for each is false
.
settings.jsdoc.allowOverrideWithoutParam
- Enables behavior with
@override
tagsettings.jsdoc.allowImplementsWithoutParam
- Enables behavior with
@implements
tagsettings.jsdoc.allowAugmentsExtendsWithoutParam
- Enables behavior with
@augments
tag or its synonym @extends
The format of the configuration is as follows:
{
"rules": {},
"settings": {
"jsdoc": {
"allowOverrideWithoutParam": true,
"allowImplementsWithoutParam": true,
"allowAugmentsExtendsWithoutParam": true
}
}
}
Settings to Configure check-types
and no-undefined-types
settings.jsdoc.preferredTypes
An option map to indicate preferred
or forbidden types (if default types are indicated here, these will
have precedence over the default recommendations for check-types
).
The keys of this map are the types to be replaced (or forbidden) and
can include the "ANY" type, *
.
The values can be:
false
to forbid the type- a string to indicate the type that should be preferred in its place
(and which
fix
mode can replace) - an object with the key
message
to provide a specific error message
when encountering the discouraged type and, if a type is to be preferred
in its place, the key replacement
to indicate the type that should be
used in its place (and which fix
mode can replace) or false
if
forbidding the type. The message string will have the following
substrings with special meaning replaced with their corresponding
value ({{tagName}}
, {{tagValue}}
, {{badType}}
, and
{{preferredType}}
, noting that the latter is of no use when one is
merely forbidding a type).
If no-undefined-types
has the option key preferredTypesDefined
set to
true
, the preferred types indicated in the settings.jsdoc.preferredTypes
map will be assumed to be defined.
Settings to Configure valid-types
settings.jsdoc.allowEmptyNamepaths
- Set to false
to disallow
empty name paths with @callback
, @event
, @listens
, @fires
,
or @emits
(these might often be expected to have an accompanying
name path, though they have some indicative value without one)settings.jsdoc.checkSeesForNamepaths
- Set this to true
to insist
that @see
only use name paths (the tag is normally permitted to
allow other text)
Settings to Configure require-returns
settings.jsdoc.forceRequireReturn
- Set to true
to always insist on
@returns
documentation regardless of implicit or explicit return
's
in the function. May be desired to flag that a project is aware of an
undefined
/void
return.
Settings to Configure require-example
settings.jsdoc.avoidExampleOnConstructors
- Set to true
to avoid the
need for an example on a constructor (whether indicated as such by a
jsdoc tag or by being within an ES6 class
).
Settings to Configure check-examples
The settings below all impact the check-examples
rule and default to
no-op/false except as noted.
JSDoc specs use of an optional <caption>
element at the beginning of
@example
. The following setting requires its use.
settings.jsdoc.captionRequired
- Require <caption>
at beginning
of any @example
JSDoc does not specify a formal means for delimiting code blocks within
@example
(it uses generic syntax highlighting techniques for its own
syntax highlighting). The following settings determine whether a given
@example
tag will have the check-examples
checks applied to it:
settings.jsdoc.exampleCodeRegex
- Regex which whitelists lintable
examples. If a parenthetical group is used, the first one will be used,
so you may wish to use (?:...)
groups where you do not wish the
first such group treated as one to include. If no parenthetical group
exists or matches, the whole matching expression will be used.
An example might be "^```(?:js|javascript)([\\s\\S]*)```$"
to only match explicitly fenced JavaScript blocks.settings.jsdoc.rejectExampleCodeRegex
- Regex blacklist which rejects
non-lintable examples (has priority over exampleCodeRegex
). An example
might be "^`"
to avoid linting fenced blocks which may indicate
a non-JavaScript language.
If neither is in use, all examples will be matched. Note also that even if
settings.jsdoc.captionRequired
is not set, any initial <caption>
will be stripped out before doing the regex matching.
The following settings determine which individual ESLint rules will be
applied to the JavaScript found within the @example
tags (as determined
to be applicable by the above regex settings). They are ordered by
decreasing precedence:
settings.jsdoc.allowInlineConfig
- If not set to false
, will allow
inline config within the @example
to override other config. Defaults
to true
.settings.jsdoc.noDefaultExampleRules
- Setting to true
will disable the
default rules which are expected to be troublesome for most documentation
use. See the section below for the specific default rules.settings.jsdoc.matchingFileName
- Setting for a dummy file name to trigger
specific rules defined in one's config; usable with ESLint .eslintrc.*
overrides
-> files
globs, to apply a desired subset of rules with
@example
(besides allowing for rules specific to examples, this setting
can be useful for enabling reuse of the same rules within @example
as
with JavaScript Markdown lintable by
other plugins, e.g.,
if one sets matchingFileName
to dummy.md
so that @example
rules will
follow one's Markdown rules).settings.jsdoc.configFile
- A config file. Corresponds to ESLint's -c
.settings.jsdoc.eslintrcForExamples
- Defaults to true
in adding rules
based on an .eslintrc.*
file. Setting to false
corresponds to
ESLint's --no-eslintrc
.settings.jsdoc.baseConfig
- An object of rules with the same schema
as .eslintrc.*
for defaults
Finally, the following rule pertains to inline disable directives:
settings.jsdoc.reportUnusedDisableDirectives
- If not set to false
,
this will report disabled directives which are not used (and thus not
needed). Defaults to true
. Corresponds to ESLint's
--report-unused-disable-directives
.
Rules Disabled by Default Unless noDefaultExampleRules
is Set to true
eol-last
- Insisting that a newline "always" be at the end is less likely
to be desired in sample code as with the code file conventionno-console
- Unlikely to have inadvertent temporary debugging within
examplesno-undef
- Many variables in examples will be undefined
.no-unused-vars
- It is common to define variables for clarity without always
using them within examples.padded-blocks
- It can generally look nicer to pad a little even if one's
code follows more stringency as far as block padding.import/no-unresolved
- One wouldn't generally expect example paths to
resolve relative to the current JavaScript file as one would with real code.import/unambiguous
- Snippets in examples are likely too short to always
include full import/export infonode/no-missing-import
- See import/no-unresolved
node/no-missing-require
- See import/no-unresolved
Rules
check-alignment
Reports invalid alignment of JSDoc block asterisks.
| |
---|
Context | ArrowFunctionExpression , FunctionDeclaration , FunctionExpression |
Tags | N/A |
The following patterns are considered problems:
function quux (foo) {
}
function quux (foo) {
}
function quux (foo) {
}
function quux (foo) {
}
function quux (foo) {
}
The following patterns are not considered problems:
function quux (foo) {
}
function quux (foo) {
}
check-examples
Ensures that (JavaScript) examples within JSDoc adhere to ESLint rules.
Works in conjunction with the following settings:
captionRequired
exampleCodeRegex
rejectExampleCodeRegex
allowInlineConfig
- Defaults to true
noDefaultExampleRules
matchingFileName
configFile
eslintrcForExamples
- Defaults to true
baseConfig
reportUnusedDisableDirectives
- Defaults to true
Inline ESLint config within @example
JavaScript is allowed, though the
disabling of ESLint directives which are not needed by the resolved rules
will be reported as with the ESLint --report-unused-disable-directives
command.
| |
---|
Context | ArrowFunctionExpression , ClassDeclaration , FunctionDeclaration , FunctionExpression |
Tags | example |
Settings | See above |
The following patterns are considered problems:
function quux () {
}
class quux {
}
function quux () {
}
function quux () {
}
function quux () {
}
function quux () {
}
function quux2 () {
}
function quux () {
}
function quux () {
}
function quux () {
}
function quux () {}
function quux () {}
The following patterns are not considered problems:
function quux () {
}
function quux () {
}
function quux () {
}
function quux () {
}
function quux () {
}
function quux () {}
function quux () {}
check-indentation
Reports invalid padding inside JSDoc block.
| |
---|
Context | ArrowFunctionExpression , FunctionDeclaration , FunctionExpression |
Tags | N/A |
The following patterns are considered problems:
function quux () {
}
The following patterns are not considered problems:
function quux () {
}
check-param-names
Ensures that parameter names in JSDoc match those in the function declaration.
| |
---|
Context | ArrowFunctionExpression , FunctionDeclaration , FunctionExpression |
Tags | param |
The following patterns are considered problems:
function quux (foo = 'FOO') {
}
function quux (foo = 'FOO') {
}
function quux (foo) {
}
function quux (foo) {
}
function quux (foo) {
}
function quux (bar, foo) {
}
function quux (foo) {
}
function quux (foo) {
}
function quux (foo, bar) {
}
function quux (foo, foo) {
}
The following patterns are not considered problems:
function quux (foo) {
}
function quux (foo) {
}
function quux (foo, bar) {
}
function quux (foo, bar, baz) {
}
function quux (foo, bar) {
}
function quux (...args) {
}
function quux ({a, b}) {
}
function quux ({a, b} = {}) {
}
function quux ([a, b] = []) {
}
function assign (employees) {
};
Deconstructing Function Parameter
eslint-plugin-jsdoc
does not validate names of parameters in function deconstruction, e.g.
function quux ({
a,
b
}) {
}
{a, b}
is an ObjectPattern
AST type and does not have a name. Therefore, the associated parameter in JSDoc block can have any name.
Likewise for the pattern [a, b]
which is an ArrayPattern
.
check-syntax
Reports against Google Closure Compiler syntax.
| |
---|
Context | ArrowFunctionExpression , FunctionDeclaration , FunctionExpression |
Tags | N/A |
The following patterns are considered problems:
function quux (foo) {
}
The following patterns are not considered problems:
function quux (foo) {
}
function quux (foo) {
}
check-tag-names
Reports invalid block tag names.
Valid JSDoc 3 Block Tags are:
abstract
access
alias
async
augments
author
borrows
callback
class
classdesc
constant
constructs
copyright
default
deprecated
description
enum
event
example
exports
external
file
fires
function
generator
global
hideconstructor
ignore
implements
inheritdoc
inner
instance
interface
kind
lends
license
listens
member
memberof
memberof!
mixes
mixin
module
name
namespace
override
package
param
private
property
protected
public
readonly
requires
returns
see
since
static
summary
this
throws
todo
tutorial
type
typedef
variation
version
yields
| |
---|
Context | ArrowFunctionExpression , FunctionDeclaration , FunctionExpression |
Tags | N/A |
Settings | tagNamePreference , additionalTagNames |
The following patterns are considered problems:
function quux () {
}
function quux () {
}
function quux (foo) {
}
function quux (foo) {
}
function quux (foo) {
}
function quux (foo) {
}
function quux (foo) {
}
function quux (foo) {
}
The following patterns are not considered problems:
function quux (foo) {
}
function quux (foo) {
}
function quux (foo) {
}
function quux (foo) {
}
function quux (foo) {
}
function quux (foo) {}
check-types
Reports invalid types.
By default, ensures that case of native types is the same as in this list:
undefined
null
boolean
number
string
object
Array
Date
RegExp
Options
check-types
allows one option:
- An option object with the key
noDefaults
to insist that only the
supplied option type map is to be used, and that the default preferences
(such as "string" over "String") will not be enforced.
See also the documentation on settings.jsdoc.preferredTypes
which impacts
the behavior of check-types
.
Why not capital case everything?
Why are boolean
, number
and string
exempt from starting with a capital letter? Let's take string
as an example. In Javascript, everything is an object. The string Object has prototypes for string functions such as .toUpperCase()
.
Fortunately we don't have to write new String()
everywhere in our code. Javascript will automatically wrap string primitives into string Objects when we're applying a string function to a string primitive. This way the memory footprint is a tiny little bit smaller, and the GC has less work to do.
So in a sense, there two types of strings in Javascript; {string}
literals, also called primitives and {String}
Objects. We use the primitives because it's easier to write and uses less memory. {String}
and {string}
are technically both valid, but they are not the same.
new String('lard')
'lard'
new String('lard') === 'lard'
To make things more confusing, there are also object literals and object Objects. But object literals are still static Objects and object Objects are instantiated Objects. So an object primitive is still an object Object.
However, Object.create(null)
objects are not instanceof Object
, however, so
in the case of this Object we lower-case to indicate possible support for
these objects.
Basically, for primitives, we want to define the type as a primitive, because that's what we use in 99.9% of cases. For everything else, we use the type rather than the primitive. Otherwise it would all just be {object}
.
In short: It's not about consistency, rather about the 99.9% use case. (And some
functions might not even support the objects if they are checking for identity.)
type name | typeof | check-types | testcase |
---|
Array | object | Array | ([]) instanceof Array -> true |
Date | object | Date | (new Date()) instanceof Date -> true |
RegExp | object | RegExp | (new RegExp(/.+/)) instanceof RegExp -> true |
Object | object | object | ({}) instanceof Object -> true but Object.create(null) instanceof Object -> false |
Boolean | boolean | boolean | (true) instanceof Boolean -> false |
Number | number | number | (41) instanceof Number -> false |
String | string | string | ("test") instanceof String -> false |
| |
---|
Context | ArrowFunctionExpression , FunctionDeclaration , FunctionExpression |
Tags | class , constant , enum , implements , member , module , namespace , param , property , returns , throws , type , typedef , yields |
Aliases | constructor , const , var , arg , argument , prop , return , exception |
Closure-only | package , private , protected , public , static |
The following patterns are considered problems:
function quux (foo) {
}
function quux (foo) {
}
function quux () {
}
function quux (foo, bar, baz) {
}
function quux (foo, bar, baz) {
}
function qux(foo) {
}
function qux(foo) {
}
function qux(foo) {
}
function qux(foo, bar, baz) {
}
function qux(foo) {
}
function qux(foo) {
}
function qux(foo, bar) {
}
function qux(foo, bar) {
}
function qux(foo) {
}
function qux(foo) {
}
function qux(baz) {
}
function qux(baz) {
}
function qux(foo, bar) {
}
The following patterns are not considered problems:
function quux (foo, bar, baz) {
}
function quux (foo, bar, baz) {
}
function quux (foo, bar, baz) {
}
function qux(foo) {
}
function qux(foo) {
}
function qux(foo) {
}
function qux(foo) {
}
function quux () {
}
function quux (foo) {
}
implements-on-classes
Reports an issue with any non-constructor function using @implements
.
Constructor functions, whether marked with @class
, @constructs
, or being
an ES6 class constructor, will not be flagged.
| |
---|
Context | ArrowFunctionExpression , FunctionDeclaration , FunctionExpression |
Tags | implements (prevented) |
The following patterns are considered problems:
function quux () {
}
The following patterns are not considered problems:
function quux () {
}
function quux () {
}
class quux {
constructor () {
}
}
match-description
Enforces a regular expression pattern on descriptions.
The default is this basic expression to match English sentences (Support
for Unicode upper case may be added in a future version when it can be handled
by our supported Node versions):
^([A-Z]|[`\\d_])([\\s\\S]*[.?!`])?$
You can supply your own expression passing a matchDescription
string on
the options object.
{
'jsdoc/match-description': ['error', {matchDescription: '[A-Z].*\\.'}]
}
If you want different regular expressions to apply to tags, you may use
the tags
option object:
{
'jsdoc/match-description': ['error', {tags: {
param: '\\- [A-Z].*\\.',
returns: '[A-Z].*\\.'
}}]
}
In place of a string, you can also add true
to indicate that a particular
tag should be linted with the matchDescription
value (or the default).
{
'jsdoc/match-description': ['error', {tags: {
param: true,
returns: true
}}]
}
By default, only the main function description is linted.
| |
---|
Context | ArrowFunctionExpression , FunctionDeclaration , FunctionExpression |
Tags | N/A by default but see tags options |
Settings | |
Options | tags (allows for 'param', 'arg', 'argument', 'returns', 'return'), matchDescription |
The following patterns are considered problems:
function quux () {
}
function quux () {
}
function quux () {
}
function quux () {
}
function quux (foo) {
}
function quux (foo) {
}
function quux (foo) {
}
function quux (foo) {
}
function quux (foo) {
}
function longDescription (foo) {
}
function quux (foo) {
}
function quux (foo) {
}
function quux (foo) {
}
function quux (foo) {
}
function quux () {
}
The following patterns are not considered problems:
function quux () {
}
function quux () {
}
function quux () {
}
function quux () {
}
function quux () {
}
function quux () {
}
function quux () {
}
function quux () {
}
function quux () {
}
function quux () {
}
function quux () {
}
function quux () {
}
function quux () {
}
function quux () {
}
function quux () {
}
newline-after-description
Enforces a consistent padding of the block description.
This rule takes one argument. If it is "always"
then a problem is raised when there is a newline after the description. If it is "never"
then a problem is raised when there is no newline after the description. The default value is "always"
.
| |
---|
Context | ArrowFunctionExpression , FunctionDeclaration , FunctionExpression |
Tags | N/A |
The following patterns are considered problems:
function quux () {
}
function quux () {
}
The following patterns are not considered problems:
function quux () {
}
function quux () {
}
function quux () {
}
function quux () {
}
no-types
This rule reports types being used on @param
or @returns
.
The rule is intended to prevent the indication of types on tags where
the type information would be redundant with TypeScript.
| |
---|
Context | ArrowFunctionExpression , FunctionDeclaration , FunctionExpression |
Tags | param , returns |
Aliases | arg , argument , return |
The following patterns are considered problems:
function quux (foo) {
}
function quux () {
}
The following patterns are not considered problems:
function quux (foo) {
}
no-undefined-types
Checks that types in jsdoc comments are defined. This can be used to check
unimported types.
When enabling this rule, types in jsdoc comments will resolve as used
variables, i.e. will not be marked as unused by no-unused-vars
.
In addition to considering globals found in code (or in ESLint-indicated
globals
) as defined, the following tags will also be checked for
name(path) definitions to also serve as a potential "type" for checking
the tag types in the table below:
callback
, class
(or constructor
), constant
(or const
), event
, external
(or host
), function
(or func
or method
), interface
, member
(or var
), mixin
, name
, namespace
, typedef
.
The following types are always considered defined.
null
, undefined
, string
, boolean
number
, NaN
, Infinity
any
, *
Array
, Object
, RegExp
, Date
, Function
Options
An option object may have the following keys:
preferredTypesDefined
- If this option is set to true
and preferred
types are indicated within settings.jsdoc.preferredTypes
, any such
types will be assumed to be defined as well.definedTypes
- This array can be populated to indicate other types which
are automatically considered as defined (in addition to globals, etc.)
| |
---|
Context | ArrowFunctionExpression , FunctionDeclaration , FunctionExpression |
Tags | class , constant , enum , implements , member , module , namespace , param , property , returns , throws , type , typedef , yields |
Aliases | constructor , const , var , arg , argument , prop , return , exception , yield |
Closure-only | package , private , protected , public , static |
The following patterns are considered problems:
function quux(foo) {
}
function quux(foo, bar) {
}
function quux(foo, bar, baz) {
}
function quux(foo, bar, baz) {
}
The following patterns are not considered problems:
function quux(foo) {
}
function quux(foo) {
}
class MyClass {}
function quux(foo) {
console.log(foo);
}
quux(0);
const MyType = require('my-library').MyType;
function quux(foo) {
}
const MyType = require('my-library').MyType;
function quux(foo) {
}
import {MyType} from 'my-library';
function quux(foo, bar, baz) {
}
function quux(foo, bar) {
}
function quux(foo) {
}
function quux(foo) {
}
function testFunction(callback) {
callback();
}
function foo () {
}
function quux(foo, bar) {
}
function quux(foo, bar, baz) {
}
require-description-complete-sentence
Requires that block description and tag description are written in complete sentences, i.e.,
- Description must start with an uppercase alphabetical character.
- Paragraphs must start with an uppercase alphabetical character.
- Sentences must end with a period.
- Every line in a paragraph (except the first) which starts with an uppercase character must be preceded by a line ending with a period.
| |
---|
Context | ArrowFunctionExpression , FunctionDeclaration , FunctionExpression |
Tags | param , returns |
Aliases | arg , argument , return |
The following patterns are considered problems:
function quux () {
}
function quux () {
}
function quux () {
}
function quux () {
}
function quux () {
}
function quux () {
}
function quux (foo) {
}
function quux (foo) {
}
function quux (foo) {
}
function quux (foo) {
}
function quux (foo) {
}
function longDescription (foo) {
}
function quux (foo) {
}
function quux (foo) {
}
function quux (foo) {
}
function quux (foo) {
}
The following patterns are not considered problems:
function quux () {
}
function quux () {
}
function quux () {
}
function quux () {
}
function quux () {
}
function quux () {
}
function quux () {
}
function quux () {
}
function quux () {
}
function quux () {
}
function quux () {
}
function quux () {
}
require-description
Requires that all functions have a description.
- All functions must have a
@description
tag. - Every description tag must have a non-empty description that explains the purpose of the method.
Options
contexts
- Set to a string or array of strings representing the AST context
where you wish the rule to be applied (e.g., ClassDeclaration
for ES6 classes).noDefaults
- By default, contexts
will permit ArrowFunctionExpression
,
FunctionDeclaration
, and FunctionExpression
. Set this instead to true
to
have contexts
override these.
| |
---|
Context | ArrowFunctionExpression , FunctionDeclaration , FunctionExpression ; others when contexts option enabled |
Tags | description |
Aliases | desc |
Options | contexts , noDefaults |
The following patterns are considered problems:
function quux () {
}
class quux {
}
class quux {
}
class quux {
}
function quux () {
}
The following patterns are not considered problems:
function quux () {
}
function quux () {
}
function quux () {
}
class quux {
}
function quux () {
}
require-example
Requires that all functions have examples.
- All functions must have one or more
@example
tags. - Every example tag must have a non-empty description that explains the method's usage.
| |
---|
Context | ArrowFunctionExpression , FunctionDeclaration , FunctionExpression |
Tags | example |
Settings | avoidExampleOnConstructors |
The following patterns are considered problems:
function quux () {
}
function quux () {
}
function quux () {
}
function quux () {
}
The following patterns are not considered problems:
function quux () {
}
function quux () {
}
function quux () {
}
function quux () {
}
function quux () {
}
function quux () {
}
require-hyphen-before-param-description
Requires a hyphen before the @param
description.
This rule takes one argument. If it is "always"
then a problem is raised when there is no hyphen before the description. If it is "never"
then a problem is raised when there is a hyphen before the description. The default value is "always"
.
| |
---|
Context | ArrowFunctionExpression , FunctionDeclaration , FunctionExpression |
Tags | param |
Aliases | arg , argument |
The following patterns are considered problems:
function quux () {
}
function quux () {
}
The following patterns are not considered problems:
function quux () {
}
function quux () {
}
require-jsdoc
Checks for presence of jsdoc comments, on class declarations as well as
functions.
| |
---|
Context | ArrowFunctionExpression , ClassDeclaration , FunctionDeclaration , FunctionExpression |
Tags | N/A |
Settings | exemptEmptyFunctions |
The following patterns are considered problems:
function quux (foo) {
}
function myFunction() {}
class A {
constructor(xs) {
this.a = xs;
}
}
class A {
constructor(xs) {
this.a = xs;
}
}
class A extends B {
constructor(xs) {
this.a = xs;
}
}
export class A extends B {
constructor(xs) {
this.a = xs;
}
}
export default class A extends B {
constructor(xs) {
this.a = xs;
}
}
var myFunction = () => {}
var myFunction = () => () => {}
var foo = function() {}
const foo = {bar() {}}
var foo = {bar: function() {}}
function foo (abc) {}
function foo () {
return true;
}
The following patterns are not considered problems:
var array = [1,2,3];
array.forEach(function() {});
function MyClass() {}
function myFunction() {}
var myFunction = function() {};
Object.myFunction = function () {};
var obj = {
myFunction: function () {} };
function myFunction() {}
function myFunction() {}
function myFunction() {}
var myFunction = function () {}
var myFunction = function () {}
var myFunction = function () {}
Object.myFunction = function() {}
Object.myFunction = function() {}
Object.myFunction = function() {}
(function(){})();
var object = {
myFunction: function() {} }
var object = {
myFunction: function() {} }
var object = {
myFunction: function() {} }
var array = [1,2,3];
array.filter(function() {});
Object.keys(this.options.rules || {}).forEach(function(name) {}.bind(this));
var object = { name: 'key'};
Object.keys(object).forEach(function() {})
function myFunction() {}
var myFunction = function() {}
class A {
constructor(xs) {
this.a = xs;
}
}
class App extends Component {
constructor(xs) {
this.a = xs;
}
}
export default class App extends Component {
constructor(xs) {
this.a = xs;
}
}
export class App extends Component {
constructor(xs) {
this.a = xs;
}
}
class A {
constructor(xs) {
this.a = xs;
}
}
var myFunction = () => {}
var myFunction = () => () => {}
setTimeout(() => {}, 10);
var foo = function() {}
const foo = {
bar() {}}
var foo = {
bar: function() {}}
var foo = { [function() {}]: 1 };
function foo () {}
function foo () {
return;
}
require-param-description
Requires that @param
tag has description
value.
| |
---|
Context | ArrowFunctionExpression , FunctionDeclaration , FunctionExpression |
Tags | param |
Aliases | arg , argument |
The following patterns are considered problems:
function quux (foo) {
}
function quux (foo) {
}
The following patterns are not considered problems:
function quux (foo) {
}
function quux (foo) {
}
require-param-name
Requires that all function parameters have name.
The @param
tag requires you to specify the name of the parameter you are documenting. You can also include the parameter's type, enclosed in curly brackets, and a description of the parameter.
JSDoc
| |
---|
Context | ArrowFunctionExpression , FunctionDeclaration , FunctionExpression |
Tags | param |
Aliases | arg , argument |
The following patterns are considered problems:
function quux (foo) {
}
function quux (foo) {
}
The following patterns are not considered problems:
function quux (foo) {
}
function quux (foo) {
}
require-param-type
Requires that @param
tag has type
value.
| |
---|
Context | ArrowFunctionExpression , FunctionDeclaration , FunctionExpression |
Tags | param |
Aliases | arg , argument |
The following patterns are considered problems:
function quux (foo) {
}
function quux (foo) {
}
The following patterns are not considered problems:
function quux (foo) {
}
function quux (foo) {
}
require-param
Requires that all function parameters are documented.
| |
---|
Context | ArrowFunctionExpression , FunctionDeclaration , FunctionExpression |
Tags | param |
Aliases | arg , argument |
Settings | allowOverrideWithoutParam , allowImplementsWithoutParam , allowAugmentsExtendsWithoutParam |
The following patterns are considered problems:
function quux (foo) {
}
function quux (foo) {
}
function quux (foo, bar) {
}
function quux (foo) {
}
function quux (foo) {
}
function quux (foo) {
}
function quux (foo) {
}
class A {
quux (foo) {
}
}
class A {
quux (foo) {
}
}
class A {
quux (foo) {
}
}
class A {
quux (foo) {
}
}
The following patterns are not considered problems:
function quux (foo) {
}
function quux (foo) {
}
function quux (foo) {
}
function quux (foo) {
}
function quux (foo) {
}
function quux (foo) {
}
function quux (foo) {
}
function quux (foo) {
}
function quux (foo) {
}
function quux (foo) {
}
function quux (foo) {
}
class A {
quux (foo) {
}
}
class A {
quux (foo) {
}
}
class A {
quux (foo) {
}
}
class A {
quux (foo) {
}
}
class A {
quux (foo) {
}
}
class A {
quux (foo) {
}
}
class A {
quux (foo) {
}
}
class A {
quux (foo) {
}
}
function quux (foo) {
}
require-returns-check
Checks if the return expression exists in function body and in the comment.
| |
---|
Context | ArrowFunctionExpression , FunctionDeclaration , FunctionExpression |
Tags | returns |
Aliases | return |
The following patterns are considered problems:
function quux (foo) {
}
function quux (foo) {
}
const quux = () => {}
function quux () {
return foo;
}
const language = {
get name() {
this._name = name;
}
}
The following patterns are not considered problems:
function quux () {
return foo;
}
function quux () {
return foo;
}
function quux () {
return foo;
}
function quux () {
}
const quux = () => foo;
function quux () {}
function quux () {}
async function quux() {}
const quux = async function () {}
const quux = async () => {}
function quux () {
throw new Error('must be implemented by subclass!');
}
function quux () {
throw new Error('must be implemented by subclass!');
}
function quux () {
}
function quux () {
}
function quux () {
}
require-returns-description
Requires that @returns
tag has description
value.
| |
---|
Context | ArrowFunctionExpression , FunctionDeclaration , FunctionExpression |
Tags | returns |
Aliases | return |
The following patterns are considered problems:
function quux (foo) {
}
function quux (foo) {
}
The following patterns are not considered problems:
function quux () {
}
function quux () {
}
function quux () {
}
function quux () {
}
require-returns-type
Requires that @returns
tag has type
value.
| |
---|
Context | ArrowFunctionExpression , FunctionDeclaration , FunctionExpression |
Tags | returns |
Aliases | return |
The following patterns are considered problems:
function quux () {
}
function quux () {
}
function quux () {
}
The following patterns are not considered problems:
function quux () {
}
require-returns
Requires returns are documented.
| |
---|
Context | ArrowFunctionExpression , FunctionDeclaration , FunctionExpression |
Tags | returns |
Aliases | return |
Settings | forceRequireReturn |
The following patterns are considered problems:
function quux (foo) {
return foo;
}
const foo = () => ({
bar: 'baz'
})
const foo = bar=>({ bar })
const foo = bar => bar.baz()
function quux (foo) {
return foo;
}
async function quux() {}
const quux = async function () {}
const quux = async () => {}
function quux () {
}
const language = {
get name() {
return this._name;
}
}
The following patterns are not considered problems:
function quux () {
return foo;
}
function quux () {
}
function quux (bar) {
bar.filter(baz => {
return baz.corge();
})
}
function quux (bar) {
return bar.filter(baz => {
return baz.corge();
})
}
const quux = (bar) => bar.filter(({ corge }) => corge())
function quux (foo) {
}
function quux (foo) {
}
function quux (foo) {
}
function quux (foo) {
}
function quux (foo) {
return foo;
}
function quux (foo) {
}
function quux (foo) {
}
function quux () {
return {a: foo};
}
const quux = () => ({a: foo});
const quux = () => {
return {a: foo}
};
function quux () {
}
const quux = () => {
}
function quux () {
}
const quux = () => {
}
function quux () {
}
const quux = () => {
}
class Foo {
constructor () {
}
}
const language = {
set name(name) {
this._name = name;
}
}
valid-types
Requires all types to be valid JSDoc or Closure compiler types without syntax errors.
Also impacts behaviors on namepath (or event)-defining and pointing tags:
- Name(path)-defining tags:
@class
, @constructor
, @constant
, @const
, @external
, @host
, @function
, @func
, @method
, @interface
, @member
, @var
, @mixin
, @name
, @namespace
, @typedef
- Name(path)-pointing tags:
@alias
, @augments
, @extends
, @lends
, @memberof
, @memberof!
, @mixes
, @this
- Name(path)-defining tags (which may have value without namepath):
@callback
, @event
- Name(path)-pointing tags (which may have value without namepath):
@listens
, @fires
, @emits
- Name(path)-pointing tags (multiple names in one):
@borrows
...with the following applying to the above sets:
- Expect tags in set 1-4 to have a valid namepath if present
- Prevent sets 3-4 from being empty by setting
allowEmptyNamepaths
to false
as these tags might have some indicative value without a path (but sets 1-2 will always fail if empty) - For the special case of set 5, i.e.,
@borrows <that namepath> as <this namepath>
, check that both namepaths are present and valid and ensure there is an as
between them.
| |
---|
Context | ArrowFunctionExpression , FunctionDeclaration , FunctionExpression |
Tags | For name only unless otherwise stated: alias , augments , borrows , callback , class (for name and type), constant (for name and type), enum (for type), event , external , fires , function , implements (for type), interface , lends , listens , member (for name and type), memberof , memberof! , mixes , mixin , module (for name and type), name , namespace (for name and type), param (for name and type), property (for name and type), returns (for type), this , throws (for type), type (for type), typedef (for name and type), yields (for type) |
Aliases | extends , constructor , const , host , emits , func , method , var , arg , argument , prop , return , exception , yield |
Closure-only | For type only: package , private , protected , public , static |
Settings | allowEmptyNamepaths , checkSeesForNamepaths |
The following patterns are considered problems:
function quux() {
}
function quux() {
}
function quux() {
}
function quux() {
}
function quux() {
}
function quux() {
}
function quux() {
}
The following patterns are not considered problems:
function quux() {
}
function quux() {
}
function quux() {
}
function quux() {
}
function quux() {
}
function quux() {
}
function quux() {
}
function quux() {
}