-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
feat(eslint-plugin): [lines-around-comment] add extension rule #5327
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
Conversation
Thanks for the PR, @chbdetta! typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community. The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately. Thanks again! 🙏 Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently on https://opencollective.com/typescript-eslint. As a thank you, your profile/company logo will be added to our main README which receives thousands of unique visitors per day. |
✅ Deploy Preview for typescript-eslint ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #5327 +/- ##
==========================================
+ Coverage 91.36% 91.44% +0.07%
==========================================
Files 368 369 +1
Lines 12592 12709 +117
Branches 3707 3745 +38
==========================================
+ Hits 11505 11622 +117
Misses 772 772
Partials 315 315
Flags with carried forward coverage won't be shown. Click here to find out more.
|
@JoshuaKGoldberg and @bradzacher any chance to merge this in? |
@pkuczynski dont ping maintainers directly. It's poor etiquette to try and bump priorities by doing this. It doesn't change our priorities, and just spams people anyone watching this PR as well as the tagged. We have a documented review process and this PR is in the queue. We are volunteers, and have little time to allocate to everything. |
Dear @bradzacher apologies for my impatience. I know how much work it is to manage popular open source package, as I am maintainer myself. I just noticed quite some activity in other PRs beings commented and merged, and this felt a bit abandoned, so indeed I wanted to bring a little bit of your attention... |
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.
Ok! Thanks for sending this in and for all the thorough tests ported over from ESLint. This is a really great start. ❤️
But: I think we can reduce the lines of coded added by a bunch by reusing the base rule (rules.Program()
).
/** | ||
* Returns whether or not comments are at the array start or not. | ||
*/ | ||
function isCommentAtArrayStart(token: TSESTree.Token): boolean { |
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.
The base rule already covers arrays, classes, and basically everything else that's not an interface or type. So you should be able to do what other rule extensions do and call the base rule to reuse its logic:
const rules = baseRule.create(context, [options]);
return {
Program(): void {
rules.Program();
comments.forEach(...);
I prototyped this locally and it looks to get pretty much all the existing test cases. Is there any reason why this strategy wouldn't work?
It'd be a real shame to copy & paste so much core ESLint rule logic. We'd then have to maintain it all over time.
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 for the late response! I finally have time to take a look at this.
Because the base rule will always report false positive errors on TS codes (which is what we're fixing here), to reuse the Program()
from the base rule, I have to create a custom context.report
function that silences errors caused by TS-codes and feed it to the base rule. (Please let me know if there is a proper way to silence an error report)
By reusing the base rule, I can now skip checking non-TS codes since they are already handled by the base rule.
Changes in 30825c6
Woo! Amazing to see a PR on this, I was about to start one until I noticed this 🥳 |
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.
there are a large number of uncovered lines in the rule - could you please add some more test cases to get the coverage higher?
Co-authored-by: Brad Zacher <brad.zacher@gmail.com>
@viveleroi the status is what it looks like: we posted some suggestions and are waiting on @chbdetta to address them. Normally I'd link to our Contributing guide to indicate that we normally ask folks to not post in PRs asking for updates. But I can see why you'd post now - it's been a month with no updates. I just updated #5942 to also mention PRs. |
👋 @chbdetta just checking in, do you still have the time to work on this? No worries if not - we can always close the PR and let the issue be open for anybody else who wants to send a PR. |
@JoshuaKGoldberg Thanks for bumping this! I was able to look at this again. I ran into some trouble getting the coverage report locally after merging the latest main, do you know how to resolve this?
|
...huh, I could swear I've responded to that message about testing coverage failure somewhere else. But can't find it. Anyway:
|
@JoshuaKGoldberg @bradzacher please review the PR again. I delegate most of the non-TS cases to the base rule so I only keep the TS-related test cases. |
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.
All right, I poked at this as much as I can and it looks good to me! Thanks for sending this in & waiting for the review @chbdetta. 🔥
@bradzacher I'll wait another week or two for your review if you have time since you've been looking at extension rules a bunch. Otherwise I'll be good to merge in.
PR Checklist
Overview
port the
eslint/lines-around-comment
rule and support interface and type literalsOptions
in addition to the base rule options, this adds: