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

Autogenerate many rule options list with eslint-doc-generator #2917

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

bmish
Copy link
Contributor

@bmish bmish commented Nov 4, 2023

I'm trying out this new feature I implemented that generates the lists of rule options from the rule schemas. More info:

This requires quite a bit of cleanup including:

  • Moving option info into the schema as much as possible
  • Reorganizing rule docs so that the options list can fit nicely

I noticed that many rules do not even mention their options in their docs today, or do so incompletely.

Since there are so many rules with options, I haven't quite fully filled out and perfected all the schemas/docs yet, but it's a start.

Note that I avoided adding the auto-generated lists to rules with complex option formats which aren't all supported yet by eslint-doc-generator.

@bmish bmish marked this pull request as draft November 4, 2023 22:24
Copy link
Member

@ljharb ljharb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like a great start :-)

Comment on lines +18 to +19
| `importFunctions` | String[] |
| `webpackChunknameFormat` | String |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

string should be lowercase, i think

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you know of any related example / precedent for displaying variable/data types one way or the other, or have any other reasoning behind your preference? I'm open to considering a change.

The current reasoning is that arbitrary, user-defined values like the name of an option are displayed in backticks, whereas values from a fixed set like variable types are simply capitalized.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here's a comprehensive example that shows how we format different kinds of values: https://github.com/bmish/eslint-doc-generator/blob/main/docs/examples/eslint-plugin-test/docs/rules/no-foo.md#options

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

String means an object - the constructor - and string means a primitive. It's what typeof produces for primitives as well.

TypeScript follows this convention as well.

Comment on lines +17 to +18
| `ignoreTypeImports` | Boolean | `false` |
| `max` | Number | `10` |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same with all the primitive types

@ljharb ljharb added the docs label Nov 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging this pull request may close these issues.

2 participants