Change default rule schema to `schema: []`
See original GitHub issueThe problem you want to solve.
Today, rule schemas (meta.schema) are optional. This has the following effects:
- If a rule does not specify a schema, nothing is enforced.
- Rules with options may not have a schema specified, despite it being best practice to specify a schema for rule options. This increases the chances of developers passing invalid rule options and encountering unexpected behavior / bugs in rules.
- If a rule author wants to enforce that no options are passed to their rule, they have to manually specify
schema: []
, otherwise itβs possible that developers could accidentally provide useless rule options to their rule without knowing it.
There is an existing, third-party lint rule eslint-plugin/require-meta-schema to enforce that rules have schemas, but this rule is optional and thus not widely used.
Your take on the correct solution to problem.
Change the default rule schema to schema: []
to enforce that no rule options are passed to rules that do not specify a schema.
This has the desirable consequence of requiring rules with options to begin specifying their schema if they did not already.
This would be a breaking change suitable for the next major release.
Making ESLintβs default behavior more strict like this goes along with many recent changes to tighten validation (i.e. more RuleTester class validation in ESLint 7, increased rule configuration validation in ESLint 6, etc) to improve rule usability and reduce the chance of mistakes.
And in addition to the obvious benefits of increased rule schema usage such as reduced chance of silent mistakes/bugs, being able to rely on having rule schemas available could enable:
- Improved/autogenerated documentation regarding rule options
- TypeScript-style autocomplete/IntelliSense when configuring a rule
Are you willing to submit a pull request to implement this change?
Yes. I am open to writing the RFC and implementation.
Issue Analytics
- State:
- Created 2 years ago
- Reactions:2
- Comments:15 (14 by maintainers)
Top GitHub Comments
I put together a repository called eslint-ecosystem-analyzer with scripts to perform an analysis of the ESLint plugin ecosystem. It retrieves the top ESLint plugin repositories by searching GitHub and then clones them so that metrics can be computed.
The analysis output is included below. To summarize the findings:
These findings seem very favorable toward:
In order to move forward with both of these breaking changes:
Let me know what you think of this analysis and plan. If it sounds good, I could start on RFCs.
That is amazing π Iβm also supportive and feel much better knowing that the vast majority of the ecosystem is already prepared.