fix: correct Rule typings
#20199
fix: correct Rule typings
#20199
Conversation
✅ Deploy Preview for docs-eslint canceled.
|
DMartens
left a comment
There was a problem hiding this comment.
Changes LGTM, thanks for finding the inconsistencies.
Is there any reason this is marked as a draft?
|
@DMartens I pushed some more typing improvements. I believe eslint/rewrite#298 should fix the CI. Let me know your thoughts! |
lib/types/index.d.ts
Outdated
|
|
||
| interface ReportDescriptorOptionsBase { | ||
| data?: { [key: string]: string }; | ||
| data?: Record<string, unknown> | undefined; |
There was a problem hiding this comment.
Why explicitly allow undefined? This property should either be unset or an object as the context.report method ignores any falsy value for the data.
There was a problem hiding this comment.
This mirrors the data type from the core package, which is what context.report uses. Since data can be explicitly set to undefined without ESLint throwing, I don’t see this as a bug. Removing undefined might even be a breaking change.
There was a problem hiding this comment.
My point is that data can be explicitly set to null, false or any other falsy value without throwing. But the point of the types in this case is to guide to rule developers and not expose implementation details.
Further eslint also does not throw for passing additional properties to context.report but I do not think we should add an index signature to explicitly allow it.
To put in other words, why should a rule developer explicitly set data: undefined?
(Side note: I think the undefined is included because many use optional properties together with undefined to not differentiate between missing property and setting it explicitly to undefined)
There was a problem hiding this comment.
What I'm saying is that the data in context.report is typed as Record<string, unknown> | undefined. This change simply mirrors the data type from the core package. If we want to omit undefined, that would need to be addressed in the core package first, which I believe would be a breaking change. Unless, of course, you're suggesting we diverge the data type here from the core one?
There was a problem hiding this comment.
The next version of @eslint/core will export types that we can use here. I’ve reverted my last commit and opened a separate PR to refactor this: #20235
|
Thanks for finding additional inconsistencies. |
This reverts commit 0a5aae4.
Prerequisites checklist
What is the purpose of this pull request? (put an "X" next to an item)
[ ] Documentation update
[x] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofix to a rule
[ ] Add a CLI option
[ ] Add something to the core
[ ] Other, please explain:
What changes did you make? (Give an overview)
onUnreachableCodePathSegmentStartandonUnreachableCodePathSegmentEndtoRule.RuleListenerto match emitted code-path events.RuleListeneras the visitor:Rule.RuleModule’sVisitoris nowRuleListener, andcreate()returnsRuleListener.JSRuleDefinition’sVisitoris also set toRule.RuleListener.Is there anything you'd like reviewers to focus on?