Skip to content

Commit

Permalink
docs: wrapping to 80 chars. (for IDE that don't have wrapping set)
Browse files Browse the repository at this point in the history
  • Loading branch information
brettz9 committed Jul 13, 2020
1 parent 20fe098 commit 6f94d12
Show file tree
Hide file tree
Showing 24 changed files with 296 additions and 182 deletions.
53 changes: 35 additions & 18 deletions .README/README.md
Expand Up @@ -12,13 +12,15 @@ JSDoc linting rules for ESLint.

## Installation

Install [ESLint](https://www.github.com/eslint/eslint) either locally or globally.
Install [ESLint](https://www.github.com/eslint/eslint) either locally or
globally.

```sh
npm install --save-dev eslint
```

If you have installed `ESLint` globally, you have to install JSDoc plugin globally too. Otherwise, install it locally.
If you have installed `ESLint` globally, you have to install JSDoc plugin
globally too. Otherwise, install it locally.

```sh
npm install --save-dev eslint-plugin-jsdoc
Expand Down Expand Up @@ -134,10 +136,11 @@ how many line breaks to add when a block is missing.
- `settings.jsdoc.mode` - Set to `typescript`, `closure`, or `jsdoc` (the
default unless the `@typescript-eslint` parser is in use in which case
`typescript` will be the default).
Note that if you do not wish to use separate `.eslintrc.*` files for a project
containing both JavaScript and TypeScript, you can also use [`overrides`](https://eslint.org/docs/user-guide/configuring). You may also set to `"permissive"` to
try to be as accommodating to any of the styles, but this is not recommended.
Currently is used for the following:
Note that if you do not wish to use separate `.eslintrc.*` files for a
project containing both JavaScript and TypeScript, you can also use
[`overrides`](https://eslint.org/docs/user-guide/configuring). You may also
set to `"permissive"` to try to be as accommodating to any of the styles,
but this is not recommended. Currently is used for the following:
- `check-tag-names`: Determine valid tags and aliases
- `no-undefined-types`: Only check `@template` for types in "closure" and
"typescript" modes
Expand All @@ -159,7 +162,9 @@ how many line breaks to add when a block is missing.

### 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.
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.

```json
{
Expand All @@ -175,11 +180,15 @@ Use `settings.jsdoc.tagNamePreference` to configure a preferred alias name for a
}
```

Note: ESLint does not allow settings to have keys which conflict with `Object.prototype` e.g. `'constructor'`. To work around this, you can use the key `'tag constructor'`.
Note: ESLint does not allow settings to have keys which conflict with
`Object.prototype` e.g. `'constructor'`. To work around this, you can use the
key `'tag constructor'`.

One may also use an object with a `message` and `replacement`.

The following will report the message `@extends is to be used over @augments as it is more evocative of classes than @augments` upon encountering `@augments`.
The following will report the message
`@extends is to be used over @augments as it is more evocative of classes than @augments`
upon encountering `@augments`.

```json
{
Expand All @@ -197,7 +206,8 @@ The following will report the message `@extends is to be used over @augments as
}
```

If one wishes to reject a normally valid tag, e.g., `@todo`, one may set the tag to `false`:
If one wishes to reject a normally valid tag, e.g., `@todo`, one may set the
tag to `false`:

```json
{
Expand All @@ -215,7 +225,8 @@ If one wishes to reject a normally valid tag, e.g., `@todo`, one may set the tag
A project wishing to ensure no blocks are left excluded from entering the
documentation, might wish to prevent the `@ignore` tag in the above manner.

Or one may set the targeted tag to an object with a custom `message`, but without a `replacement` property:
Or one may set the targeted tag to an object with a custom `message`, but
without a `replacement` property:

```json
{
Expand All @@ -232,8 +243,9 @@ Or one may set the targeted tag to an object with a custom `message`, but withou
}
```

Note that the preferred tags indicated in the `settings.jsdoc.tagNamePreference`
map will be assumed to be defined by `check-tag-names`.
Note that the preferred tags indicated in the
`settings.jsdoc.tagNamePreference` map will be assumed to be defined by
`check-tag-names`.

See `check-tag-names` for how that fact can be used to set an alias to itself
to allow both the alias and the default (since aliases are otherwise not
Expand Down Expand Up @@ -285,7 +297,8 @@ for any of the "require" rules (i.e., `require-param`, `require-description`,
`require-example`, or `require-returns`).

* `settings.jsdoc.overrideReplacesDocs` (`@override`) - Defaults to `true`
* `settings.jsdoc.augmentsExtendsReplacesDocs` (`@augments` or its alias `@extends`) - Defaults to `false`.
* `settings.jsdoc.augmentsExtendsReplacesDocs` (`@augments` or its alias
`@extends`) - Defaults to `false`.
* `settings.jsdoc.implementsReplacesDocs` (`@implements`) - Defaults to `false`

The format of the configuration is as follows:
Expand Down Expand Up @@ -353,8 +366,9 @@ The format of the configuration is as follows:
can replace)
- `false` (for forbidding the type)

Note that the preferred types indicated as targets in `settings.jsdoc.preferredTypes`
map will be assumed to be defined by `no-undefined-types`.
Note that the preferred types indicated as targets in
`settings.jsdoc.preferredTypes` map will be assumed to be defined by
`no-undefined-types`.

See the option of `check-types`, `unifyParentAndChildTypeChecks`, for
how the keys of `preferredTypes` may have `<>` or `.<>` (or just `.`)
Expand Down Expand Up @@ -409,8 +423,11 @@ Tip: If you want to more deeply understand not just the resulting AST tree
structures for any given code but also the syntax for esquery selectors so
that you can, for example, find only those nodes with a child of a certain
type, you can set the "Transform" feature to ESLint and test out
esquery selectors in place of the selector expression (e.g., replace `'VariableDeclaration > VariableDeclarator > Identifier[name="someVar"]'` as
we have [here](https://astexplorer.net/#/gist/71a93130c19599d6f197bddb29c13a59/latest)) to the selector you wish so as to get messages reported in the bottom right
esquery selectors in place of the selector expression (e.g., replace
`'VariableDeclaration > VariableDeclarator > Identifier[name="someVar"]'` as
we have
[here](https://astexplorer.net/#/gist/71a93130c19599d6f197bddb29c13a59/latest))
to the selector you wish so as to get messages reported in the bottom right
pane which match your [esquery](https://github.com/estools/esquery/#readme)
selector).

Expand Down
4 changes: 2 additions & 2 deletions .README/rules/check-examples.md
Expand Up @@ -123,8 +123,8 @@ decreasing precedence:
use extra lines within examples just for easier illustration
purposes.
* `no-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.
* `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
Expand Down
7 changes: 4 additions & 3 deletions .README/rules/check-syntax.md
@@ -1,8 +1,9 @@
### `check-syntax`

Reports against syntax not encouraged for the mode (e.g., Google Closure Compiler
in "jsdoc" or "typescript" mode). Note that this rule will not chekc for types
that are wholly invalid for a given mode, as that is covered by `valid-types`.
Reports against syntax not encouraged for the mode (e.g., Google Closure
Compiler in "jsdoc" or "typescript" mode). Note that this rule will not check
for types that are wholly invalid for a given mode, as that is covered by
`valid-types`.

Currently checks against:

Expand Down
20 changes: 11 additions & 9 deletions .README/rules/check-tag-names.md
Expand Up @@ -75,10 +75,11 @@ version
yields
```

`modifies` is also supported (see [source](https://github.com/jsdoc/jsdoc/blob/master/packages/jsdoc/lib/jsdoc/tag/dictionary/definitions.js#L594)) but is undocumented.
`modifies` is also supported (see [source](https://github.com/jsdoc/jsdoc/blob/master/packages/jsdoc/lib/jsdoc/tag/dictionary/definitions.js#L594))
but is undocumented.

The following synonyms are also recognized if you set them in `tagNamePreference`
as a key (or replacement):
The following synonyms are also recognized if you set them in
`tagNamePreference` as a key (or replacement):

```
arg
Expand All @@ -102,19 +103,20 @@ virtual
yield
```

If you wish to allow in certain cases both a primary tag name and its alias(es),
you can set a normally non-preferred tag name to itself to indicate that you want
to allow both the default tag (in this case `@returns`) and a non-default
(in this case `return`):
If you wish to allow in certain cases both a primary tag name and its
alias(es), you can set a normally non-preferred tag name to itself to indicate
that you want to allow both the default tag (in this case `@returns`) and a
non-default (in this case `return`):

```js
"tagNamePreference": {
"return": "return",
}
```

Because the tags indicated as replacements in `settings.jsdoc.tagNamePreference`
will automatically be considered as valid, the above works.
Because the tags indicated as replacements in
`settings.jsdoc.tagNamePreference` will automatically be considered as valid,
the above works.

For [TypeScript](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html#supported-jsdoc)
(or Closure), when `settings.jsdoc.mode` is set to `typescript` or `closure`,
Expand Down
33 changes: 25 additions & 8 deletions .README/rules/check-types.md
Expand Up @@ -2,7 +2,8 @@

Reports invalid types.

By default, ensures that the casing of native types is the same as in this list:
By default, ensures that the casing of native types is the same as in this
list:

```
undefined
Expand Down Expand Up @@ -69,28 +70,44 @@ the `valid-types` rule to report parsing errors.

#### 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()`.
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](https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)) has less work to do.
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](https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)) 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.
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.

```js
new String('lard') // String {0: "l", 1: "a", 2: "r", 3: "d", length: 4}
'lard' // "lard"
new String('lard') === 'lard' // false
```

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.
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}`.
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.)
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
--|--|--|--
Expand Down
4 changes: 2 additions & 2 deletions .README/rules/implements-on-classes.md
Expand Up @@ -22,8 +22,8 @@ for finding function blocks not attached to a function declaration or
expression, i.e., `@callback` or `@function` (or its aliases `@func` or
`@method`) (including those associated with an `@interface`).

See the ["AST and Selectors"](#eslint-plugin-jsdoc-advanced-ast-and-selectors) section of our README for
more on the expected format.
See the ["AST and Selectors"](#eslint-plugin-jsdoc-advanced-ast-and-selectors)
section of our README for more on the expected format.

|||
|---|---|
Expand Down
14 changes: 7 additions & 7 deletions .README/rules/match-description.md
Expand Up @@ -81,18 +81,18 @@ default `match-description`, you may use `mainDescription`:
```

There is no need to add `mainDescription: true`, as by default, the main
function (and only the main function) is linted, though you may disable checking
it by setting it to `false`.
function (and only the main function) is linted, though you may disable
checking it by setting it to `false`.

##### `contexts`

Set this to an array of strings representing the AST context
where you wish the rule to be applied (e.g., `ClassDeclaration` for ES6 classes).
Overrides the default contexts (see below). Set to `"any"` if you want
the rule to apply to any jsdoc block throughout your files.
where you wish the rule to be applied (e.g., `ClassDeclaration` for ES6
classes). Overrides the default contexts (see below). Set to `"any"` if you
want the rule to apply to any jsdoc block throughout your files.

See the ["AST and Selectors"](#eslint-plugin-jsdoc-advanced-ast-and-selectors) section of our README for
more on the expected format.
See the ["AST and Selectors"](#eslint-plugin-jsdoc-advanced-ast-and-selectors)
section of our README for more on the expected format.

|||
|---|---|
Expand Down
5 changes: 4 additions & 1 deletion .README/rules/newline-after-description.md
Expand Up @@ -4,7 +4,10 @@ Enforces a consistent padding of the block description.

#### Options

This rule allows one optional string argument. If it is `"always"` then a problem is raised when there is no newline after the description. If it is `"never"` then a problem is raised when there is a newline after the description. The default value is `"always"`.
This rule allows one optional string argument. If it is `"always"` then a
problem is raised when there is no newline after the description. If it is
`"never"` then a problem is raised when there is a newline after the
description. The default value is `"always"`.

|||
|---|---|
Expand Down
4 changes: 2 additions & 2 deletions .README/rules/no-defaults.md
Expand Up @@ -32,8 +32,8 @@ for finding function blocks not attached to a function declaration or
expression, i.e., `@callback` or `@function` (or its aliases `@func` or
`@method`) (including those associated with an `@interface`).

See the ["AST and Selectors"](#eslint-plugin-jsdoc-advanced-ast-and-selectors) section of our README for
more on the expected format.
See the ["AST and Selectors"](#eslint-plugin-jsdoc-advanced-ast-and-selectors)
section of our README for more on the expected format.

|||
|---|---|
Expand Down
4 changes: 2 additions & 2 deletions .README/rules/no-types.md
Expand Up @@ -17,8 +17,8 @@ for finding function blocks not attached to a function declaration or
expression, i.e., `@callback` or `@function` (or its aliases `@func` or
`@method`) (including those associated with an `@interface`).

See the ["AST and Selectors"](#eslint-plugin-jsdoc-advanced-ast-and-selectors) section of our README for
more on the expected format.
See the ["AST and Selectors"](#eslint-plugin-jsdoc-advanced-ast-and-selectors)
section of our README for more on the expected format.

|||
|---|---|
Expand Down
6 changes: 5 additions & 1 deletion .README/rules/no-undefined-types.md
Expand Up @@ -11,7 +11,11 @@ In addition to considering globals found in code (or in ESLint-indicated
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`, `@template` (for "closure" or "typescript" `settings.jsdoc.mode` only), `@typedef`.
`@callback`, `@class` (or `@constructor`), `@constant` (or `@const`),
`@event`, `@external` (or `@host`), `@function` (or `@func` or `@method`),
`@interface`, `@member` (or `@var`), `@mixin`, `@name`, `@namespace`,
`@template` (for "closure" or "typescript" `settings.jsdoc.mode` only),
`@typedef`.

The following tags will also be checked but only when the mode is `closure`:

Expand Down
8 changes: 5 additions & 3 deletions .README/rules/require-description-complete-sentence.md
@@ -1,7 +1,7 @@
### `require-description-complete-sentence`

Requires that block description, explicit `@description`, and `@param`/`@returns`
tag descriptions are written in complete sentences, i.e.,
Requires that block description, explicit `@description`, and
`@param`/`@returns` tag descriptions are written in complete sentences, i.e.,

* Description must start with an uppercase alphabetical character.
* Paragraphs must start with an uppercase alphabetical character.
Expand All @@ -23,7 +23,9 @@ add them within this option.

```js
{
'jsdoc/require-description-complete-sentence': ['error', {tags: ['see', 'copyright']}]
'jsdoc/require-description-complete-sentence': ['error', {
tags: ['see', 'copyright']
}]
}
```

Expand Down
9 changes: 6 additions & 3 deletions .README/rules/require-description.md
Expand Up @@ -24,9 +24,12 @@ An options object may have any of the following properties:
- `descriptionStyle` - Whether to accept implicit descriptions (`"body"`) or
`@description` tags (`"tag"`) as satisfying the rule. Set to `"any"` to
accept either style. Defaults to `"body"`.
- `checkConstructors` - A value indicating whether `constructor`s should be checked. Defaults to `true`.
- `checkGetters` - A value indicating whether getters should be checked. Defaults to `true`.
- `checkSetters` - A value indicating whether getters should be checked. Defaults to `true`.
- `checkConstructors` - A value indicating whether `constructor`s should be
checked. Defaults to `true`.
- `checkGetters` - A value indicating whether getters should be checked.
Defaults to `true`.
- `checkSetters` - A value indicating whether getters should be checked.
Defaults to `true`.

| | |
| -------- | ------------------------------------------------------------------------------------------------------------- |
Expand Down

0 comments on commit 6f94d12

Please sign in to comment.