bmish / eslint-doc-generator

Automatic documentation generator for ESLint plugins and rules.

eslint-doc-generator

Automatic documentation generator for ESLint plugins and rules. Inspired by documentation conventions from ESLint and top ESLint plugins.

Generates the following documentation covering a wide variety of rule metadata:

• README.md rules table
• README.md configs table
• Rule doc titles and notices
• Rule doc options lists

Also performs configurable section consistency checks on rule docs:

• Contains an ## Options or ## Config section and mentions each named option (for rules with options)

Table of contents

• Motivation
• Setup
  • Scripts
  • Update README.md
  • Update rule docs
  • Configure linting
• Usage
• Examples
  • Rules list table
  • Configs list table
  • Rule doc notices
  • Rule doc options lists
  • Users
• Configuration options
  • Column and notice types
  • --config-format
  • --rule-doc-title-format
  • Configuration file
  • Badges
• Compatibility
  • Build tools
  • markdownlint
  • prettier
• Semantic versioning policy
• Related

Motivation

• Standardize documentation across thousands of ESLint plugins and rules
• Improve the discoverability of key rule information and thus rule usability
• Streamline the process of adding/updating rules while ensuring documentation is kept up-to-date
• Eliminate the custom documentation scripts and tests previously built and maintained by many ESLint plugins

Setup

Install it:

npm i --save-dev eslint-doc-generator

Scripts

Add scripts to package.json:

• Both a lint script to ensure everything is up-to-date in CI and an update script for contributors to run locally
• Add any config options in the update:eslint-docs script only (or use a config file)
• Alternative scripts may be needed with build tools, markdownlint, or prettier

{
  "scripts": {
    "lint": "npm-run-all \"lint:*\"",
    "lint:docs": "markdownlint \"**/*.md\"",
    "lint:eslint-docs": "npm run update:eslint-docs -- --check",
    "lint:js": "eslint .",
    "update:eslint-docs": "eslint-doc-generator"
  }
}

Update README.md

Delete any old rules list from your README.md. A new one will be automatically added to your ## Rules section (along with the following marker comments if they don't already exist):

<!-- begin auto-generated rules list -->
<!-- end auto-generated rules list -->

Optionally, add these marker comments to your README.md in a ## Configs section or similar location (uses the meta.docs.description property exported by each config if available):

<!-- begin auto-generated configs list -->
<!-- end auto-generated configs list -->

Update rule docs

Delete any old recommended/fixable/etc. notices from your rule docs. A new title and notices will be automatically added to the top of each rule doc (along with a marker comment if it doesn't already exist).

<!-- end auto-generated rule header -->

Optionally, add these marker comments to your rule docs in an ## Options section or similar location:

<!-- begin auto-generated rule options list -->
<!-- end auto-generated rule options list -->

Note that rule option lists are subject-to-change as we add support for more kinds and properties of schemas. To fully take advantage of them, you'll want to ensure your rules have the meta.schema property fleshed out with properties like description, type, enum, default, required, deprecated.

Configure linting

And be sure to enable the recommended rules from eslint-plugin-eslint-plugin as well as:

• eslint-plugin/require-meta-docs-description to ensure your rules have consistent descriptions for use in the generated docs
• eslint-plugin/require-meta-docs-url to ensure your rule docs are linked to by editors on highlighted violations
• eslint-plugin/require-meta-schema to ensure your rules have schemas for use in determining options

Usage

Run the script from package.json to start out or any time you add a rule or update rule metadata in your plugin:

npm run update:eslint-docs

Examples

For examples, see our users or the in-house examples below. Note that the in-house examples intentionally show all possible columns and notices.

Rules list table

See the generated rules table and legend in our example README.md.

Configs list table

See the generated configs table in our example README.md.

Rule doc notices

See the generated rule doc title and notices in our example rule docs no-foo.md, prefer-bar.md, require-baz.md.

Rule doc options lists

See the generated rule doc options lists in our example rule doc no-foo.md.

Users

This tool is used by popular ESLint plugins like:

• eslint-plugin-ava
• eslint-plugin-ember
• eslint-plugin-eslint-plugin
• eslint-plugin-import
• eslint-plugin-jest
• eslint-plugin-jsx-a11y
• eslint-plugin-promise
• eslint-plugin-qunit
• eslint-plugin-react
• eslint-plugin-unicorn

Configuration options

These can be provided as CLI options or as config file options. All options are optional.

The CLI has an optional path argument if you need to point the CLI to an ESLint plugin directory that isn't just the current directory:

eslint-doc-generator path/to/eslint-plugin

There's also a postprocess option that's only available via a config file.

Name	Description	Default
--check	Whether to check for and fail if there is a diff. Any diff will be displayed but no output will be written to files. Typically used during CI.	false
--config-emoji	Custom emoji to use for a config. Format is config-name,emoji. Option can be repeated.	Default emojis are provided for common configs. See Badges for an alternative to emojis.
--config-format	The format to use for config names. See choices in below table.	name
--ignore-config	Config to ignore from being displayed. Often used for an all config. Option can be repeated.
--ignore-deprecated-rules	Whether to ignore deprecated rules from being checked, displayed, or updated.	false
--init-rule-docs	Whether to create rule doc files if they don't yet exist.	false
--path-rule-doc	Path to markdown file for each rule doc. Use {name} placeholder for the rule name. A function can also be provided for this option via a config file.	docs/rules/{name}.md
--path-rule-list	Path to markdown file where the rules table list should live. Option can be repeated.	README.md
--rule-doc-notices	Ordered, comma-separated list of notices to display in rule doc. Non-applicable notices will be hidden. See choices in below table.	deprecated, configs, fixableAndHasSuggestions, requiresTypeChecking
--rule-doc-section-exclude	Disallowed section in each rule doc. Exit with failure if present. Option can be repeated.
--rule-doc-section-include	Required section in each rule doc. Exit with failure if missing. Option can be repeated.
--rule-doc-section-options	Whether to require an "Options" or "Config" rule doc section and mention of any named options for rules with options.	true
--rule-doc-title-format	The format to use for rule doc titles. See choices in below table.	desc-parens-prefix-name
--rule-list-columns	Ordered, comma-separated list of columns to display in rule list. Empty columns will be hidden. See choices in below table.	name, description, configsError, configsWarn, configsOff, fixable, hasSuggestions, requiresTypeChecking, deprecated
--rule-list-split	Rule property(s) to split the rules list by. A separate list and header will be created for each value. Example: meta.type. A function can also be provided for this option via a config file.
--url-configs	Link to documentation about the ESLint configurations exported by the plugin.
--url-rule-doc	Link to documentation for each rule. Useful when it differs from the rule doc path on disk (e.g. custom documentation site in use). Use {name} placeholder for the rule name. A function can also be provided for this option via a config file.

Column and notice types

These are the types of rule metadata that are available for display in rule list columns (--rule-list-columns) and/or rule doc notices (--rule-doc-notices).

Emoji	Type	Column?	Notice?	Description
💼	configsError	Yes	No	Whether a rule is set to error in a config.
🚫	configsOff	Yes	No	Whether a rule is set to off in a config.
⚠️	configsWarn	Yes	No	Whether a rule is set to warn in a config.
💼	configs	No	Yes	What configs set a rule to what severities.
❌	deprecated	Yes	Yes	Whether a rule is deprecated (i.e. likely to be removed/renamed in a future major version).
	description	Yes	Yes	The rule description.
🔧💡	fixableAndHasSuggestions	Yes	Yes	Whether a rule is fixable and/or has suggestions.
🔧	fixable	Yes	Yes	Whether a rule is fixable.
💡	hasSuggestions	Yes	Yes	Whether a rule has suggestions.
	name	Yes	No	The rule name.
⚙️	options	Yes	Yes	Whether a rule has options.
💭	requiresTypeChecking	Yes	Yes	Whether a rule requires type checking.
🗂️	type	Yes	Yes	The rule type (problem, suggestion, or layout).

--config-format

Where recommended is the config name and eslint-plugin-test is the plugin name.

Value	Example
name (default)	recommended
plugin-colon-prefix-name	plugin:test/recommended
prefix-name	test/recommended

--rule-doc-title-format

Where no-foo is the rule name, Disallow use of foo is the rule description, and eslint-plugin-test is the plugin name.

Value	Example
desc	# Disallow use of foo
desc-parens-name	# Disallow use of foo (no-foo)
desc-parens-prefix-name (default)	# Disallow use of foo (test/no-foo)
name	# no-foo
prefix-name	# test/no-foo

Configuration file

There are a few ways to create a config file (as an alternative to passing the options via CLI):

• An object exported by .eslint-doc-generatorrc.js, .eslint-doc-generatorrc.json, or any other config file format/name supported by cosmiconfig
• An object under the eslint-doc-generator key in package.json

Config files support all the CLI options but in camelCase.

Some options are exclusive to a JavaScript-based config file:

• postprocess - A function-only option useful for applying custom transformations such as formatting with tools like prettier. See prettier example.
• ruleListSplit with a function - This is useful for customizing the grouping of rules into lists.

Example .eslint-doc-generatorrc.js:

/** @type {import('eslint-doc-generator').GenerateOptions} */
const config = {
  ignoreConfig: ['all'],
};

module.exports = config;

Example .eslint-doc-generatorrc.js with pathRuleDoc function:

/** @type {import('eslint-doc-generator').GenerateOptions} */
const config = {
  pathRuleDoc(name) {
    // e.g. rule name format is `some-plugin/some-rule`, and rule is in a monorepo under different package.
    const [plugin, rule] = name.split("/");
    return `packages/eslint-plugin-${plugin}/src/rules/${rule}.md`;
  },
};

module.exports = config;

Example .eslint-doc-generatorrc.js with ruleListSplit function:

/** @type {import('eslint-doc-generator').GenerateOptions} */
const config = {
  ruleListSplit(rules) {
    return [
      {
        // No header for this list.
        rules: rules.filter(([name, rule]) => !rule.meta.someProp),
      },
      {
        title: 'Foo',
        rules: rules.filter(([name, rule]) => rule.meta.someProp === 'foo'),
      },
      {
        title: 'Bar',
        rules: rules.filter(([name, rule]) => rule.meta.someProp === 'bar'),
      },
    ];
  },
};

module.exports = config;

Example .eslint-doc-generatorrc.js with urlRuleDoc function:

/** @type {import('eslint-doc-generator').GenerateOptions} */
const config = {
  urlRuleDoc(name, page) {
    if (page === 'README.md') {
      // Use URLs only in the readme.
      return `https://example.com/rules/${name}.html`;
    }
  },
};

module.exports = config;

Badges

While emojis are the recommended representations of configs that a rule belongs to, you can alternatively use a text/image/icon badge for configs by supplying the following markdown for the emoji using the --config-emoji option.

For example, here's the markdown for a text badge representing a custom fun config that displays in blue (note that the markdown includes alt text followed by the image URL):

![fun config badge](https://img.shields.io/badge/-fun-blue.svg)

Here's how you'd configure it:

/** @type {import('eslint-doc-generator').GenerateOptions} */
const config = {
  configEmoji: [
    ['fun', '![fun config badge](https://img.shields.io/badge/-fun-blue.svg)'],
  ],
};

module.exports = config;

And how it looks:

Compatibility

Build tools

If you have a build step for your code like Babel or TypeScript, you may need to adjust your scripts to run your build before this tool to ensure the documentation is generated from the latest plugin information:

{
  "build": "tsc",
  "update:eslint-docs": "npm run build && eslint-doc-generator"
}

markdownlint

The output of this tool should be compatible with the default configuration of markdownlint, which you might use to lint your markdown. If it's not, you can follow the prettier example to tweak your scripts or use the postprocess option. See here for an example of markdownlint's Node API for applying fixes to use in your postprocess function.

prettier

If you use prettier to format your markdown, you can provide a postprocess function to ensure the documentation generated by this tool is formatted correctly:

const prettier = require('prettier');
const { prettier: prettierRC } = require('./package.json'); // or wherever your prettier config lies

/** @type {import('eslint-doc-generator').GenerateOptions} */
const config = {
  postprocess: (content, path) =>
    prettier.format(content, { ...prettierRC, parser: 'markdown' }),
};

module.exports = config;

Alternatively, you can configure your scripts to run prettier after this tool:

{
  "format": "prettier --write .",
  "lint:eslint-docs": "npm run update:eslint-docs && git diff --exit-code",
  "update:eslint-docs": "eslint-doc-generator && npm run format"
}

Semantic versioning policy

This tool follows semantic versioning.

New features will be released as a minor version, while bug fixes will be released as a patch version.

Breaking changes will be released as a major version and include:

• Changing an option default
• Renaming or removing an option
• Other backwards-incompatible changes to the CLI / API
• Raising Node or ESLint version requirements

Tweaks to the generated documentation output can take place in any type of release including minor and patch versions. This can break your build, as even a small formatting change will cause a diff, but you can simply re-run the tool to fix.

Related

• eslint-plugin-eslint-plugin - Linter for ESLint plugins (related list)
• generator-eslint - Generates initial ESLint plugin and rule files but without the sophisticated documentation provided by eslint-doc-generator

eslint-doc-generator's Issues

Don't suggest using `&&` in example NPM scripts in README

We can use npm-run-all to avoid this for better compatibility.

Indicate which configs a rule is set to `warn` severity level in

Currently, we only check for error severity.

Related: #21

Needed to unblock: lo1tuma/eslint-plugin-mocha#330

More robust detection of README rules section

Right now, we only detect a ## Rules section when looking for where to insert the rules list into the README when the marker comments are missing. While this is the most common section name, we should detect additional variations:

• ## 🍟 Rules (eslint-plugin-ember)
• ## Custom rules (eslint-plugin-square)
• ## List of supported rules (eslint-plugin-react)

Auto-generate a badge for each config

So the user doesn't have to do it themselves unless they want to.

If an emoji isn't specified for a config, and we don't see a badge for it in the README, automatically add one to the bottom of the README.

Add options for non-standard paths for README.md or rule doc files

Might need a config option to specify the path to these if non-standard:

Standard paths:

• README.md
• docs/rules/[rule-name].md

Override options:

• --path-readme
• --path-rule-doc

Also considered:

• --rule-doc-path for grouping with existing rule doc options
• --rule-list-path for grouping with existing rule list options

Fix test coverage check

Jest is not indicating why function test coverage is not at 100%. We want all coverage to be 100%.

eslint-doc-generator/jest.config.cjs

Line 21 in 83563c5

functions: 96.77, // TODO: Should be 100% but unclear what function is missing coverage.

Change first column in rule list from `Rule` to `Name`

This is more common and it's already in the ## Rules section.

Avoid crashing for deprecated rules without rule docs

Include rule name prefix in rule doc title

Before

# Do not use `foo` (`no-foo`)

After

# Do not use `foo` (`test/no-foo`)

Where the plugin is called eslint-plugin-test.

This avoids a potential hiccup since users will need to use the prefix to refer to the rule in their own codebases.

Handled scoped plugin names

Example:

• @typescript-eslint/eslint-plugin

eslint-doc-generator/lib/package-json.ts

Line 42 in 83563c5

return pluginPackageJson.name.replace('eslint-plugin-', ''); // TODO: also need to support scoped plugins.

Throw error when rule doc file is missing

Throw a helpful error message rather than crash.

Separate issue for creating the missing rule docs: #79

[BUG] Prettier not found

Apparently the library expects that i installed prettier in my project.

node:internal/errors:465
    ErrorCaptureStackTrace(err);
    ^

Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'prettier' imported from ...\node_modules\.pnpm\[email protected]_ypn2ylkkyfa5i233caldtndbqa\node_modules\eslint-doc-generator\dist\lib\markdown.js
    at new NodeError (node:internal/errors:372:5)
    at packageResolve (node:internal/modules/esm/resolve:954:9)
    at moduleResolve (node:internal/modules/esm/resolve:1003:20)
    at defaultResolve (node:internal/modules/esm/resolve:1218:11)
    at ESMLoader.resolve (node:internal/modules/esm/loader:580:30)
    at ESMLoader.getModuleJob (node:internal/modules/esm/loader:294:18)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/module_job:80:40)
    at link (node:internal/modules/esm/module_job:78:36) {
  code: 'ERR_MODULE_NOT_FOUND'
}
 ELIFECYCLE  Command failed with exit code 1.

EXPECTED RESULT:
shouldn't crash if prettier isn't my project.

ACTUAL RESULT:
crash if prettier isn't my project.

ENVIROMENT:
Windows 10
Node 16

Use more third-party ESLint types instead of defining our own

Release at least one version that supports Node 12.22

Will unblock:

• platinumazure/eslint-plugin-qunit#242

Custom config emojis

Allow specifying the emoji to represent each config.

Examples of config option:

--config-emoji "recommended,✅" (default)
--config-emoji "stylistic,🎨"

Add option to split rule list by `meta.docs.category` or potentially other criteria

Config options:

--rule-list-split-by-category
--rule-list-split-by meta.docs.category

This would help unblock adoption in:

• docs.category - https://github.com/ember-cli/eslint-plugin-ember#-configurations
• type - jest-community/eslint-plugin-jest#1263 (comment)

Option to consolidate rule doc notices

Example of eslint-plugin-unicorn combining the fixable/suggestions notices into one:

🔧💡 This rule is [auto-fixable](https://eslint.org/docs/user-guide/command-line-interface#fixing-problems) and provides [suggestions](https://eslint.org/docs/developer-guide/working-with-rules#providing-suggestions).

https://github.com/sindresorhus/eslint-plugin-unicorn/blob/main/docs/rules/no-array-push-push.md

Automatically generate rules list emojis legend in README

Potential issue with importing Windows paths

Node 16 Windows CI is failing attempting to add this tool to an eslint plugin in square/eslint-plugin-square#764.

node:internal/errors:477
    ErrorCaptureStackTrace(err);
    ^

Error [ERR_UNSUPPORTED_ESM_URL_SCHEME]: Only URLs with a scheme in: file, data are supported by the default ESM loader. On Windows, absolute paths must be valid file:// URLs. Received protocol 'd:'
    at new NodeError (node:internal/errors:387:5)
    at throwIfUnsupportedURLScheme (node:internal/modules/esm/resolve:1116:11)
    at defaultResolve (node:internal/modules/esm/resolve:1196:3)
    at nextResolve (node:internal/modules/esm/loader:165:28)
    at ESMLoader.resolve (node:internal/modules/esm/loader:844:30)
    at ESMLoader.getModuleJob (node:internal/modules/esm/loader:431:18)
    at ESMLoader.import (node:internal/modules/esm/loader:528:22)
    at importModuleDynamically (node:internal/modules/esm/translators:110:35)
    at importModuleDynamicallyCallback (node:internal/process/esm_loader:35:[14](https://github.com/square/eslint-plugin-square/actions/runs/3170797584/jobs/5163651883#step:5:15))
    at loadPlugin (file:///D:/a/eslint-plugin-square/eslint-plugin-square/node_modules/eslint-doc-generator/dist/lib/package-json.js:[20](https://github.com/square/eslint-plugin-square/actions/runs/3170797584/jobs/5163651883#step:5:21):33) {
  code: 'ERR_UNSUPPORTED_ESM_URL_SCHEME'
}
error Command failed with exit code 1.

https://github.com/square/eslint-plugin-square/actions/runs/3170797584/jobs/5163651883

Option to ignore certain configs from being displayed

By default, we ignore all in some places. This should be configurable with a repeatable option.

• --ignore-config all
• --ignore-config foo

Handle the `deprecated`/`schema` properties that can exist on function-style rules

See:

• eslint-doc-generator/lib/generator.ts

  Line 94 in 663344b

  deprecated: false, // TODO: figure out how to access `deprecated` property that can be exported from function-style rules.

• eslint-community/eslint-plugin-eslint-plugin#311

Related:

• #353

Only use prettier to format affected doc content

Not everyone wants to format their docs with prettier. It also creates a big diff when running this tool. By default, we should only use prettier to format the doc sections this tool manages. We could have an option (default off) to use it to format the entire affected docs.

Handle various possible names for rule doc options section

We currently check for an ## Options section in a rule doc when a rule has options. We should allow other common names for that section.

Split tests file

All our tests our in the massive generate-test.ts test file. Sticking to acceptance tests and avoiding most unit tests has been helpful as it has allowed quicker refactoring of functions without having to update a ton of unit tests. But we should split this giant acceptance test file into multiple files based on category of test.

Capitalize first letter of rule description and remove trailing period for rule doc title

Many descriptions begin with a lowercase letter as enforced by this lint rule:

https://github.com/eslint-community/eslint-plugin-eslint-plugin/blob/main/docs/rules/require-meta-docs-description.md

Also remove any trailing period so the formatting is more like a title.

Add option to create missing rule docs

--init-rule-docs to create any missing rule docs.

Fail if there are no rule docs to create so this option isn't left in place indefinitely.

This would only be useful for someone who hasn't created any docs for their rules yet. In that scenario, this would help save time in getting started with documentation.

The reason we need an explicit option for this (and we don't want to automatically create missing rule docs by default) is because the rule docs might live at a non-standard path and we just didn't detect them. If the plugin has a non-standard rule doc path, the user just needs to specify --path-rule-doc.

Follow-up to #78.

Potential missing blank line when adding rule list comment marker

Before:

## Rules

Existing rules section content.

After running tool:

## Rules
<!-- begin rules list -->
...
<!-- end rules list -->

Existing rules section content.

Would like to keep a blank line surrounding comment markers in this case. Follow-up to #48.

Originally posted by @bmish in #48 (comment)

Indicate which configs a rule is disabled in

Currently, we only checked when rules are enabled.

Related: #68

Automatically insert missing rule list markers in README rules section

Leaky unit test is modifying the README

Each of our tests sets up a mock filesystem using mock-fs in beforeEach() and then tears it down with mockFs.restore(); in afterEach(). This way, the tests can see the desired files, modify, and test them without affecting the actual filesystem.

For some reason, there seems to be a leak from the tests to the actual filesystem. The doc generator is inserting a rules list into README.md in between the marker comments.

<!-- begin rules list -->
<!-- end rules list -->

It's easy to accidentally check this change in. We need to figure out how to avoid this leak.

Automatically generate configs list in README

Automatically generate a table/list of configs in the README ## Configs section.

Not sure about this yet. We have the list of configs but we don't know the config descriptions. We do know the config emojis/badges if the user has specified them.

Optional columns:

• Number of rules enabled, warn, or disabled in each config

Related: #20.

Option to ignore deprecated rules from readme rules list and rule docs

--ignore-deprecated-rules

Configurable rule doc title format

We currently use the following rule doc title format:

# Do not use foo (`test/no-foo`)

We should also support another format with just the rule name without description which is also a common format in plugins:

# no-foo

Not sure which should be the default yet.

• --rule-doc-title-format desc-parens-prefix-name (default): # Do not use foo (test/no-foo)
• --rule-doc-title-format desc-parens-name: # Do not use foo (no-foo)
• --rule-doc-title-format prefix-name: # test/no-foo
• --rule-doc-title-format name: # no-foo

Use yarn instead of npm

Configurable allowed or disallowed sections enforcement

We currently only check for an ## Options section. Some users may also want to check for other sections like:

• ## Examples
• ## Rule details

Or even disallow certain sections.

This helps enforce documentation consistency.

We could have an option like:

• --rule-doc-section-include
• --rule-doc-section-exclude

Add test coverage percentage badge to README

To indicate that we have 100% test coverage.

Link to config section of README in rule notices

eslint-doc-generator/lib/rule-notices.ts

Line 21 in 83563c5

[MESSAGE_TYPE.CONFIGS]: `${EMOJI_CONFIGS} This rule is enabled in the following configs:`, // TODO: include link to configs in the plugin's README.

Might need an option to specify this URL.

Example current:

💼 This rule is enabled in the following configs: all, recommended.

Example desired:

💼 This rule is enabled in the following configs: all, recommended.

Option:

• --url-configs https://github.com/ember-cli/eslint-plugin-ember#-configurations

Detect rules enabled with options

Currently we detect rules enabled with string/number:

{
  "rules": {
    "test/no-foo": "error"
  },
}

We also need to detect the array-style option config:

{
  "rules": {
    "test/no-foo": ["error", {}]
  },
}

https://eslint.org/docs/latest/user-guide/configuring/rules#configuring-rules

Handle configs that extend other configs

module.exports = {
  extends: [require.resolve('./other-config')],
};

This causes a crash right now:

$ eslint-doc-generator
eslint-doc-generator/dist/lib/configs.js:15
        const value = config.rules[`${pluginPrefix}/${ruleName}`];
                                  ^

TypeError: Cannot read properties of undefined (reading 'test/no-foo')
    at getConfigsForRule (eslint-doc-generator/dist/lib/configs.js:15:35)
    at getRuleNoticeLines (eslint-doc-generator/dist/lib/rule-notices.js:47:28)
    at generateRuleHeaderLines (eslint-doc-generator/dist/lib/rule-notices.js:93:12)
    at generate (eslint-doc-generator/dist/lib/generator.js:62:32)
    at async Command.<anonymous> (eslint-doc-generator/dist/lib/cli.js:21:9)
error Command failed with exit code 1.

And the extended config needs to be resolved. Maybe ESLint has an API to do this for us.

Add `desc` option to `--rule-doc-title-format`

Used by eslint-plugin-unicorn: https://github.com/sindresorhus/eslint-plugin-unicorn/blob/main/docs/rules/no-array-push-push.md

Option to disable options section check

By default, we check for a ## Options or ## Config section that mentions all the named options of a rule.

We could make this configurable through an option like:

Option	Desc
--rule-doc-section-options	(default true) Whether to check for a rule doc ## Options or ## Config section and any named options when a rule has options.

Left-align rule list headers

Throw exception when no rules found

Gracefully handle this.

Add default emoji for `all` config

Similar to how we have a default emoji of ✅ for the common recommended config.

However, I can't think of a general/universal/all emoji to represent the all config.

Perhaps for other common configs as well:

• stylistic / style
• strict 🔒 (example: https://typescript-eslint.io/rules/)

Config overrides aren't considered

We likely want to consider that a rule is enabled by a config even if it's just enabled in an override from the config (not in the top-level rules of the config).

Example from square/eslint-plugin-square#764 (config line).

When rule doc is missing marker, remove old title before adding new one

Figure out how to test when prettier is not installed

Follow-up to #87.

Don't crash when no configs found

Some plugins may only define rules and no configs.

Handle various prettier config files during doc formatting

eslint-doc-generator/lib/package-json.ts

Line 54 in 83563c5

// TODO: also check other possible prettier config files.

Allow configuration in config file or package.json object

The CLI options can get very long.

This has been requested by plugin maintainers.

Options:

• cosmiconfig
• sindresorhus/pkg-conf

Also need option file schema validation:

• https://www.npmjs.com/package/ajv (json schema)