Consider adding meta.schema

[MrHBS]

It would be equivalent to ESLint’s meta.schema. This can be used for generating plugin/rule documentation websites and typegens.

[ybiquitous]

Sounds good 👍🏼

Maybe one downside is increasing a dependency that processes the JSON schema, right?

[MrHBS]

Yeah, I believe ESLint uses Ajv JSON schema validator for this.

[ybiquitous]

Great. ajv is already included in our runtime dependency tree (stylelint depends on table).

$ npm ls ajv
[email protected] /Users/masafumi.koba/git/stylelint/stylelint
├─┬ [email protected]
│ ├─┬ @eslint/[email protected]
│ │ └── [email protected] deduped
│ └── [email protected]
└─┬ [email protected]
  └── [email protected]

[ybiquitous]

@MrHBS If you're interested, could you please show more specific idea to implement this feature so that others could image it easily?

[MrHBS]

Sure. Here is an example of the schema of the accessor-pairs rule:

https://github.com/eslint/eslint/blob/1cbe1f6d38272784307c260f2375ab30e68716e8/lib/rules/accessor-pairs.js#L148-L165

And you can see here how ESLint validates the rule based on its schema.

Finally, an example of tools that utilize this schema: eslint-doc-generator and eslint-typegen.

[ybiquitous]

@MrHBS Thanks for the helpful info.

@ota-meshi Do you have any ideas to bring this feature from ESLint?

[Mouvedia]

Here's another use case for autocompletion: knowing the message arguments' names and positions.

[Mouvedia]

I am working on a pre-requisite for schema that will expedite the conversion to JSON schema.

[Mouvedia]

@MrHBS

I have a few questions:

1. Would schema be required if the rule is not CoreRule<true>? i.e. doesn't accept true or null as a primary and global secondary options

Rules with options must specify a meta.schema property…

2. If introduced, would it sunset the ...optionDescriptions argument of the validateOptions function? i.e. possible and optional would be covered by the schema

3. Would introducing a way to generate a schema for the current config be sufficient? e.g.

• stylelint schema > foo.jtd.json defaults to JSON Type Definition (default --type is "RFC8927")
• stylelint schema -c ../bar/.stylelintrc > foo.jtd.json doesn't use the default config
• stylelint schema --type="2020-12" > foo.schema.json sets the format to JSON Schema version 2020-12
• stylelint schema -r ./path/to/rule.mjs > bar.jtd.son

---

I am asking all that because I am under the impression that deprecating the current validateOptions util would be too disruptive. i.e. Just providing stylelint schema should be enough for the tools—e.g. stylelint-doc-generator, stylelint-typegen—to leverage the schema. Adding meta.schema would have cascading consequences:

• dropping validateOptions (which does its job just fine)
• making meta.schema a requirement for most rules (would have to wait the next major)
• choosing a default format (less versatile than slowly introducing new types to the --type option)

What I am getting at is, at best meta.schema could be an alternative to using validateOptions but it couldn't be a hard requirement without 2 major cycles. i.e. v17 deprecates validateOptions and v18 removes it