Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: postprocess with prettier in eslint-doc-generator #435

Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
7 changes: 7 additions & 0 deletions .eslint-doc-generatorrc.js
Original file line number Diff line number Diff line change
@@ -1,5 +1,7 @@
'use strict';

const prettier = require('prettier');

/** @type {import('eslint-doc-generator').GenerateOptions} */
module.exports = {
ignoreConfig: [
Expand All @@ -9,6 +11,11 @@ module.exports = {
'tests',
'tests-recommended',
],
postprocess: async (content, path) =>
prettier.format(content, {
...(await prettier.resolveConfig(path)),
parser: 'markdown',
}),
ruleDocSectionInclude: ['Rule Details'],
ruleListSplit: 'meta.docs.category',
urlConfigs:
Expand Down
149 changes: 73 additions & 76 deletions README.md

Large diffs are not rendered by default.

6 changes: 3 additions & 3 deletions docs/rules/consistent-output.md
Original file line number Diff line number Diff line change
Expand Up @@ -66,8 +66,8 @@ new RuleTester().run('example-rule', rule, {

This rule takes an optional string enum option with one of the following values:

* `"consistent"` - (default) if any invalid test cases have output assertions, then all invalid test cases must have output assertions
* `"always"` - always require invalid test cases to have output assertions
- `"consistent"` - (default) if any invalid test cases have output assertions, then all invalid test cases must have output assertions
- `"always"` - always require invalid test cases to have output assertions

## When Not To Use It

Expand All @@ -77,4 +77,4 @@ As mentioned in the introduction, the need for this rule is reduced as of ESLint

## Further Reading

* [`RuleTester` documentation](http://eslint.org/docs/developer-guide/working-with-plugins#testing)
- [`RuleTester` documentation](http://eslint.org/docs/developer-guide/working-with-plugins#testing)
2 changes: 1 addition & 1 deletion docs/rules/meta-property-ordering.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ This rule enforces that meta properties of a rule are placed in a consistent ord

This rule has an array option:

* `['type', 'docs', 'fixable', 'hasSuggestions', 'schema', 'messages', 'deprecated', 'replacedBy']` (default): The order that the properties of `meta` should be placed in.
- `['type', 'docs', 'fixable', 'hasSuggestions', 'schema', 'messages', 'deprecated', 'replacedBy']` (default): The order that the properties of `meta` should be placed in.

Examples of **incorrect** code for this rule:

Expand Down
42 changes: 21 additions & 21 deletions docs/rules/no-deprecated-context-methods.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,26 +10,26 @@ This rule disallows the use of deprecated methods on rule `context` objects.

The deprecated methods are:

* `getSource`
* `getSourceLines`
* `getAllComments`
* `getNodeByRangeIndex`
* `getComments`
* `getCommentsBefore`
* `getCommentsAfter`
* `getCommentsInside`
* `getJSDocComment`
* `getFirstToken`
* `getFirstTokens`
* `getLastToken`
* `getLastTokens`
* `getTokenAfter`
* `getTokenBefore`
* `getTokenByRangeStart`
* `getTokens`
* `getTokensAfter`
* `getTokensBefore`
* `getTokensBetween`
- `getSource`
- `getSourceLines`
- `getAllComments`
- `getNodeByRangeIndex`
- `getComments`
- `getCommentsBefore`
- `getCommentsAfter`
- `getCommentsInside`
- `getJSDocComment`
- `getFirstToken`
- `getFirstTokens`
- `getLastToken`
- `getLastTokens`
- `getTokenAfter`
- `getTokenBefore`
- `getTokenByRangeStart`
- `getTokens`
- `getTokensAfter`
- `getTokensBefore`
- `getTokensBetween`

Instead of using these methods, you should use the equivalent methods on [`SourceCode`](https://eslint.org/docs/developer-guide/working-with-rules#contextgetsourcecode), e.g. `context.getSourceCode().getText()` instead of `context.getSource()`.

Expand Down Expand Up @@ -71,4 +71,4 @@ If you need to support very old versions of ESLint where `SourceCode` doesn't ex

## Further Reading

* [`SourceCode` API](https://eslint.org/docs/developer-guide/working-with-rules#contextgetsourcecode)
- [`SourceCode` API](https://eslint.org/docs/developer-guide/working-with-rules#contextgetsourcecode)
8 changes: 4 additions & 4 deletions docs/rules/no-deprecated-report-api.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,8 +8,8 @@

ESLint has two APIs that rules can use to report problems.

* The [deprecated API](http://eslint.org/docs/developer-guide/working-with-rules-deprecated) accepts multiple arguments: `context.report(node, [loc], message)`.
* The ["new API"](http://eslint.org/docs/developer-guide/working-with-rules#contextreport) accepts a single argument: an object containing information about the reported problem.
- The [deprecated API](http://eslint.org/docs/developer-guide/working-with-rules-deprecated) accepts multiple arguments: `context.report(node, [loc], message)`.
- The ["new API"](http://eslint.org/docs/developer-guide/working-with-rules#contextreport) accepts a single argument: an object containing information about the reported problem.

It is recommended that all rules use the new API.

Expand Down Expand Up @@ -41,5 +41,5 @@ module.exports = {

## Further Reading

* [Deprecated rule API](http://eslint.org/docs/developer-guide/working-with-rules-deprecated)
* [New rule API](http://eslint.org/docs/developer-guide/working-with-rules)
- [Deprecated rule API](http://eslint.org/docs/developer-guide/working-with-rules-deprecated)
- [New rule API](http://eslint.org/docs/developer-guide/working-with-rules)
6 changes: 3 additions & 3 deletions docs/rules/no-missing-message-ids.md
Original file line number Diff line number Diff line change
Expand Up @@ -58,6 +58,6 @@ module.exports = {

## Further Reading

* [messageIds API](https://eslint.org/docs/developer-guide/working-with-rules#messageids)
* [no-unused-message-ids](./no-unused-message-ids.md) rule
* [prefer-message-ids](./prefer-message-ids.md) rule
- [messageIds API](https://eslint.org/docs/developer-guide/working-with-rules#messageids)
- [no-unused-message-ids](./no-unused-message-ids.md) rule
- [prefer-message-ids](./prefer-message-ids.md) rule
2 changes: 1 addition & 1 deletion docs/rules/no-missing-placeholders.md
Original file line number Diff line number Diff line change
Expand Up @@ -74,4 +74,4 @@ If you want to use rule messages that actually contain double-curly bracket text

## Further Reading

* [context.report() API](http://eslint.org/docs/developer-guide/working-with-rules#contextreport)
- [context.report() API](http://eslint.org/docs/developer-guide/working-with-rules#contextreport)
6 changes: 3 additions & 3 deletions docs/rules/no-unused-message-ids.md
Original file line number Diff line number Diff line change
Expand Up @@ -59,6 +59,6 @@ module.exports = {

## Further Reading

* [messageIds API](https://eslint.org/docs/developer-guide/working-with-rules#messageids)
* [no-missing-message-ids](./no-missing-message-ids.md) rule
* [prefer-message-ids](./prefer-message-ids.md) rule
- [messageIds API](https://eslint.org/docs/developer-guide/working-with-rules#messageids)
- [no-missing-message-ids](./no-missing-message-ids.md) rule
- [prefer-message-ids](./prefer-message-ids.md) rule
4 changes: 2 additions & 2 deletions docs/rules/no-unused-placeholders.md
Original file line number Diff line number Diff line change
Expand Up @@ -57,5 +57,5 @@ If you want to allow unused placeholders, you should turn off this rule.

## Further Reading

* [context.report() API](http://eslint.org/docs/developer-guide/working-with-rules#contextreport)
* [no-missing-placeholders](https://github.com/eslint-community/eslint-plugin-eslint-plugin/blob/master/docs/rules/no-missing-placeholders.md)
- [context.report() API](http://eslint.org/docs/developer-guide/working-with-rules#contextreport)
- [no-missing-placeholders](https://github.com/eslint-community/eslint-plugin-eslint-plugin/blob/master/docs/rules/no-missing-placeholders.md)
4 changes: 2 additions & 2 deletions docs/rules/no-useless-token-range.md
Original file line number Diff line number Diff line change
Expand Up @@ -44,8 +44,8 @@ module.exports = {

## Known Limitations

* To ensure that your `SourceCode` instances can be detected, your rule must assign `context.getSourceCode()` to a variable somewhere.
- To ensure that your `SourceCode` instances can be detected, your rule must assign `context.getSourceCode()` to a variable somewhere.

## Further Reading

* [`SourceCode` API](https://eslint.org/docs/developer-guide/working-with-rules#contextgetsourcecode)
- [`SourceCode` API](https://eslint.org/docs/developer-guide/working-with-rules#contextgetsourcecode)
12 changes: 6 additions & 6 deletions docs/rules/prefer-message-ids.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,9 +6,9 @@

When reporting a rule violation, it's preferred to provide the violation message with the `messageId` property instead of the `message` property. Message IDs provide the following benefits:

* Rule violation messages can be stored in a central `meta.messages` object for convenient management
* Rule violation messages do not need to be repeated in both the rule file and rule test file
* As a result, the barrier for changing rule violation messages is lower, encouraging more frequent contributions to improve and optimize them for the greatest clarity and usefulness
- Rule violation messages can be stored in a central `meta.messages` object for convenient management
- Rule violation messages do not need to be repeated in both the rule file and rule test file
- As a result, the barrier for changing rule violation messages is lower, encouraging more frequent contributions to improve and optimize them for the greatest clarity and usefulness

## Rule Details

Expand Down Expand Up @@ -59,6 +59,6 @@ module.exports = {

## Further Reading

* [messageIds API](https://eslint.org/docs/developer-guide/working-with-rules#messageids)
* [no-invalid-message-ids](./no-invalid-message-ids.md) rule
* [no-missing-message-ids](./no-missing-message-ids.md) rule
- [messageIds API](https://eslint.org/docs/developer-guide/working-with-rules#messageids)
- [no-invalid-message-ids](./no-invalid-message-ids.md) rule
- [no-missing-message-ids](./no-missing-message-ids.md) rule
4 changes: 3 additions & 1 deletion docs/rules/prefer-object-rule.md
Original file line number Diff line number Diff line change
Expand Up @@ -34,7 +34,9 @@ Examples of **correct** code for this rule:
/* eslint eslint-plugin/prefer-object-rule: error */

module.exports = {
meta: { /* ... */ },
meta: {
/* ... */
},
create(context) {
return {
Program() {
Expand Down
6 changes: 3 additions & 3 deletions docs/rules/prefer-placeholders.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,8 +14,8 @@ context.report({

Using placeholders is often preferred over using dynamic report messages, for a few reasons:

* They can help enforce a separation of the message and the data.
* It will be easier to migrate when ESLint starts supporting placing lint messages in metadata (see [#6740](https://github.com/eslint/eslint/issues/6740))
- They can help enforce a separation of the message and the data.
- It will be easier to migrate when ESLint starts supporting placing lint messages in metadata (see [#6740](https://github.com/eslint/eslint/issues/6740))

## Rule Details

Expand Down Expand Up @@ -63,4 +63,4 @@ If you need to use string concatenation in your report messages for some reason,

## Further Reading

* [context.report() API](http://eslint.org/docs/developer-guide/working-with-rules#contextreport)
- [context.report() API](http://eslint.org/docs/developer-guide/working-with-rules#contextreport)
2 changes: 1 addition & 1 deletion docs/rules/prefer-replace-text.md
Original file line number Diff line number Diff line change
Expand Up @@ -53,4 +53,4 @@ module.exports = {

## Further Reading

* [Applying Fixes](https://eslint.org/docs/developer-guide/working-with-rules#applying-fixes)
- [Applying Fixes](https://eslint.org/docs/developer-guide/working-with-rules#applying-fixes)
12 changes: 5 additions & 7 deletions docs/rules/report-message-format.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,16 +16,14 @@ For example, in order to mandate that all report messages begin with a capital l

```json
{
"rules": {
"eslint-plugin/report-message-format": ["error", "^[A-Z].*\\.$"]
},
"plugins": [
"eslint-plugin"
]
"rules": {
"eslint-plugin/report-message-format": ["error", "^[A-Z].*\\.$"]
},
"plugins": ["eslint-plugin"]
}
```

Note that since this rule uses static analysis and does not actually run your code, it will attempt to match report messages *before* placeholders are inserted.
Note that since this rule uses static analysis and does not actually run your code, it will attempt to match report messages _before_ placeholders are inserted.

Examples of **incorrect** code for this rule:

Expand Down
8 changes: 4 additions & 4 deletions docs/rules/require-meta-docs-description.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,9 +6,9 @@ Defining a clear and consistent description for each rule helps developers under

In particular, each rule description should begin with an allowed prefix:

* `enforce`
* `require`
* `disallow`
- `enforce`
- `require`
- `disallow`

## Rule Details

Expand Down Expand Up @@ -59,4 +59,4 @@ module.exports = {

## Further Reading

* [working-with-rules#options-schemas](https://eslint.org/docs/developer-guide/working-with-rules#options-schemas)
- [working-with-rules#options-schemas](https://eslint.org/docs/developer-guide/working-with-rules#options-schemas)
9 changes: 6 additions & 3 deletions docs/rules/require-meta-docs-url.md
Original file line number Diff line number Diff line change
Expand Up @@ -87,9 +87,12 @@ module.exports = {

```json
{
"eslint-plugin/require-meta-docs-url": ["error", {
"pattern": "https://github.com/eslint-community/eslint-plugin-eslint-plugin/blob/master/docs/rules/{{name}}.md"
}]
"eslint-plugin/require-meta-docs-url": [
"error",
{
"pattern": "https://github.com/eslint-community/eslint-plugin-eslint-plugin/blob/master/docs/rules/{{name}}.md"
}
]
}
```

Expand Down
4 changes: 2 additions & 2 deletions docs/rules/require-meta-fixable.md
Original file line number Diff line number Diff line change
Expand Up @@ -102,5 +102,5 @@ module.exports = {

## Further Reading

* [ESLint's autofix API](http://eslint.org/docs/developer-guide/working-with-rules#applying-fixes)
* [ESLint's rule basics mentioning `meta.fixable`](https://eslint.org/docs/developer-guide/working-with-rules#rule-basics)
- [ESLint's autofix API](http://eslint.org/docs/developer-guide/working-with-rules#applying-fixes)
- [ESLint's rule basics mentioning `meta.fixable`](https://eslint.org/docs/developer-guide/working-with-rules#rule-basics)
4 changes: 2 additions & 2 deletions docs/rules/require-meta-has-suggestions.md
Original file line number Diff line number Diff line change
Expand Up @@ -88,5 +88,5 @@ module.exports = {

## Further Reading

* [ESLint's suggestion API](https://eslint.org/docs/developer-guide/working-with-rules#providing-suggestions)
* [ESLint rule basics describing the `meta.hasSuggestions` property](https://eslint.org/docs/developer-guide/working-with-rules#rule-basics)
- [ESLint's suggestion API](https://eslint.org/docs/developer-guide/working-with-rules#providing-suggestions)
- [ESLint rule basics describing the `meta.hasSuggestions` property](https://eslint.org/docs/developer-guide/working-with-rules#rule-basics)
2 changes: 1 addition & 1 deletion docs/rules/require-meta-schema.md
Original file line number Diff line number Diff line change
Expand Up @@ -89,4 +89,4 @@ As mentioned in the introduction, the need for this rule is reduced as of ESLint

## Further Reading

* [working-with-rules#options-schemas](https://eslint.org/docs/developer-guide/working-with-rules#options-schemas)
- [working-with-rules#options-schemas](https://eslint.org/docs/developer-guide/working-with-rules#options-schemas)
12 changes: 6 additions & 6 deletions docs/rules/require-meta-type.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,9 +12,9 @@ Fixes in custom rules will not be applied when using `--fix-type` unless they in

This rule aims to require ESLint rules to have a valid `meta.type` property with one of the following values:

* `"problem"` means the rule is identifying code that either will cause an error or may cause a confusing behavior. Developers should consider this a high priority to resolve.
* `"suggestion"` means the rule is identifying something that could be done in a better way but no errors will occur if the code isn't changed.
* `"layout"` means the rule cares primarily about whitespace, semicolons, commas, and parentheses, all the parts of the program that determine how the code looks rather than how it executes. These rules work on parts of the code that aren't specified in the AST.
- `"problem"` means the rule is identifying code that either will cause an error or may cause a confusing behavior. Developers should consider this a high priority to resolve.
- `"suggestion"` means the rule is identifying something that could be done in a better way but no errors will occur if the code isn't changed.
- `"layout"` means the rule cares primarily about whitespace, semicolons, commas, and parentheses, all the parts of the program that determine how the code looks rather than how it executes. These rules work on parts of the code that aren't specified in the AST.

Examples of **incorrect** code for this rule:

Expand Down Expand Up @@ -51,6 +51,6 @@ module.exports = {

## Further Reading

* [command-line-interface#--fix-type](https://eslint.org/docs/user-guide/command-line-interface#--fix-type)
* [working-with-rules#rule-basics](https://eslint.org/docs/developer-guide/working-with-rules#rule-basics)
* [ESLint v5.9.0 released](https://eslint.org/blog/2018/11/eslint-v5.9.0-released#the-fix-type-option)
- [command-line-interface#--fix-type](https://eslint.org/docs/user-guide/command-line-interface#--fix-type)
- [working-with-rules#rule-basics](https://eslint.org/docs/developer-guide/working-with-rules#rule-basics)
- [ESLint v5.9.0 released](https://eslint.org/blog/2018/11/eslint-v5.9.0-released#the-fix-type-option)
2 changes: 1 addition & 1 deletion docs/rules/test-case-property-ordering.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ This rule enforces that the properties of RuleTester test cases are arranged in

This rule has an array option:

* `["code", "output", "options", "parserOptions", "errors"]` (default): The properties of a test case should be placed in a consistent order.
- `["code", "output", "options", "parserOptions", "errors"]` (default): The properties of a test case should be placed in a consistent order.

Examples of **incorrect** code for this rule:

Expand Down
18 changes: 9 additions & 9 deletions docs/rules/test-case-shorthand-strings.md
Original file line number Diff line number Diff line change
Expand Up @@ -33,10 +33,10 @@ This rule aims to enforce or disallow the use of strings as test cases.

This rule has a string option:

* `as-needed` (default): Requires the use of shorthand strings wherever possible.
* `never`: Disallows the use of shorthand strings.
* `consistent`: Requires that either all valid test cases use shorthand strings, or that no valid test cases use them.
* `consistent-as-needed`: Requires that all valid test cases use the longer object form if there are any valid test cases that require the object form. Otherwise, requires all valid test cases to use shorthand strings.
- `as-needed` (default): Requires the use of shorthand strings wherever possible.
- `never`: Disallows the use of shorthand strings.
- `consistent`: Requires that either all valid test cases use shorthand strings, or that no valid test cases use them.
- `consistent-as-needed`: Requires that all valid test cases use the longer object form if there are any valid test cases that require the object form. Otherwise, requires all valid test cases to use shorthand strings.

#### `as-needed`

Expand Down Expand Up @@ -237,15 +237,15 @@ ruleTester.run('example-rule', rule, {

## Known Limitations

* Test cases which are neither object literals nor string literals are ignored by this rule.
* In order to find your test cases, your test file needs to match the following common pattern:
* `new RuleTester()` or `new (require('eslint')).RuleTester()` is called at the top level of the file
* `ruleTester.run` is called at the top level with the same variable (or in the same expression) as the `new RuleTester` instantiation
- Test cases which are neither object literals nor string literals are ignored by this rule.
- In order to find your test cases, your test file needs to match the following common pattern:
- `new RuleTester()` or `new (require('eslint')).RuleTester()` is called at the top level of the file
- `ruleTester.run` is called at the top level with the same variable (or in the same expression) as the `new RuleTester` instantiation

## When Not To Use It

If you don't care about consistent usage of shorthand strings, you should not turn on this rule.

## Further Reading

* [`RuleTester` documentation](http://eslint.org/docs/developer-guide/working-with-plugins#testing)
- [`RuleTester` documentation](http://eslint.org/docs/developer-guide/working-with-plugins#testing)