Autogenerate many rule options list with eslint-doc-generator #2917
Conversation
bmish
force-pushed
the
edg-options-lists
branch
from
70f909c
to
1ee4458
Compare
bmish
force-pushed
the
edg-options-lists
branch
from
1ee4458
to
4c019c7
Compare
| | `importFunctions` | String[] | | ||
| | `webpackChunknameFormat` | String | |
There was a problem hiding this comment.
string should be lowercase, i think
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
| | `ignoreTypeImports` | Boolean | `false` | | ||
| | `max` | Number | `10` | |
There was a problem hiding this comment.
same with all the primitive types
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:
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.