-
-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: rewrite createRule
and RuleTester
#72
Conversation
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. |
8155716
to
a28abc6
Compare
a28abc6
to
d7fc095
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #72 +/- ##
=======================================
Coverage 96.22% 96.23%
=======================================
Files 91 91
Lines 4399 4409 +10
Branches 1497 1498 +1
=======================================
+ Hits 4233 4243 +10
Misses 160 160
Partials 6 6 ☔ View full report in Codecov by Sentry. |
createRule
and RuleTester.run
createRule
and RuleTester
@JounQin @silverwind What do you think? Do you prefer creating our own utilities or patching |
return { | ||
...ESLintUtils.RuleCreator.withoutDocs({ | ||
meta: metaWithoutDocs, | ||
...rules, | ||
}), | ||
meta: { | ||
...meta, | ||
docs: { | ||
...docs, | ||
url: docsUrl(name, commitHash), | ||
}, | ||
}, | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Under the hood we are still using ts-eslint
's RuleCreator
as much as possible, we are only overriding the returned meta
property with our meta
property.
}, | ||
} | ||
|
||
return super.run(ruleName, modifiedRule, tests) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Under the hood, run$
only does some extra modification before super.run
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is that possible to use // @ts-expect-error
here instead of create a new run$
method?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding a ts-expect-error
and moving on sounds tempting, but not a best practice here.
TypeScript throws a type mismatch for a reason: Inheritance implies subtyping, and subtype mismatch breaks the Liskov substitution. So TypeScript disallows inheriting from a base class while not being a valid subtype.
The only reason I add ts-expect-error
to the constructor
is due to the fact that ts-eslint
's RuleTester
does not extend from the ESLint one; rather, it is an alias of the ESLint's RuleTester
, while imposing an unnecessary type (essentially, ts-eslint
is declaring an incorrect type definition over other's method), which is why ts-expect-error
is applicable there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm... I think it's some kind of balance choice here, or we can say that the typings in tseslint
is incorrect? The modifications are quite huge, aren't they? I'm thinking about the maintenance vs the patch one.
Ideally we can ask eslint-doc-generator
and tseslint
to support them eachother better instead?
Let's get more feedback from others.
cc @silverwind
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, this is quite far over my head. Only feedback I would have is run$
looks a bit dirty to me. I'd suggest some camelCase name instead.
constructor(option: RuleTesterOptions = {}) { | ||
/** | ||
* The parser option is required in TSESLint.RuleTester, but not in ESLint.RuleTester. | ||
* Since TSESLint.RuleTester is just an alias of ESLint.RuleTester, we can safely ignore the type error. | ||
*/ | ||
// @ts-expect-error -- parser is not required | ||
super(option) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By extending our own RuleTester
class, we don't have to patch the type of the argument.
@JounQin Would you like to cleat the cache of the GitHub Action? It seems that the CI failed to the corrupt cache. |
I raised typescript-eslint/typescript-eslint#8897 to discuss about the optional And I notice patches are also used in tseslint's repository https://github.com/typescript-eslint/typescript-eslint/blob/main/.yarn/patches, and considering there are some HDYT? |
The debate between patches and self-implementation essentially comes down to which method is easier to maintain. IMHO, self-implementation is the superior choice. The dist files of Conversely, existing public APIs tend to offer more stability, providing a solid foundation upon which we can build. The patch method is only effective for projects that are either no longer actively maintained or are extremely active to the point where patches quickly become obsolete. |
I am closing the PR now since TypeScript ESLint 8 has addressed the custom property of |
Currently,
eslint-plugin-import-x
patches@typescript-eslint/utils
to add custom properties like thecategory
and modify properties like therecommended
.The PR accomplishes the same thing, by doing some TypeScript exercises instead.