feat: support JSRuleDefinition type
#19604
Conversation
✅ Deploy Preview for docs-eslint ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
….com/lumirlumir/fork-eslint into feat-support-js-rule-definition-type
lib/types/index.d.ts
Outdated
| type JSRuleDefinitionTypeOptions = { | ||
| RuleOptions: unknown[]; | ||
| MessageIds: string; | ||
| ExtRuleDocs: Record<string, unknown>; | ||
| }; |
There was a problem hiding this comment.
We keep defining this structure in every plugin. Maybe we should make a generic RuleDefinitionTypeOptions in @eslint/core instead of copying this everywhere? @fasttime what do you think?
There was a problem hiding this comment.
We are already exporting an interface with that name (https://github.com/eslint/rewrite/blob/core-v0.13.0/packages/core/src/types.ts#L545-L556), but we could export a new type just for those options that should be customizable for a language-specific RuleDefinition generic type.
There was a problem hiding this comment.
I opened an issue in the rewrite repo: eslint/rewrite#177
|
I've moved |
Prerequisites checklist
What is the purpose of this pull request? (put an "X" next to an item)
[ ] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofix to a rule
[ ] Add a CLI option
[X] Add something to the core
[ ] Other, please explain:
What changes did you make? (Give an overview)
Hello,
This PR addresses #19521.
I've implemented tests for
JSRuleDefinitionby referencing the existing test in@eslint/markdown.The most notable change in this PR is the addition of the
JSRuleDefinitiontype to theRulenamespace, in order to follow the existing convention.Is there anything you'd like reviewers to focus on?
Fixes: #19521