-
Notifications
You must be signed in to change notification settings - Fork 16
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
Improvements #7
Improvements #7
Conversation
Also check tightened PR_RE against pathname
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.
Wow, thanks a lot for the contributions! I left a few comments, but overall looks pretty good.
@@ -120,35 +120,13 @@ | |||
} | |||
} | |||
|
|||
function getFixesUrl() { |
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.
was this not used?
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.
No it wasn't.
review.js
Outdated
revs.push(login) | ||
} | ||
} | ||
|
||
return revs | ||
} | ||
|
||
function getCollaborators(cb) { | ||
function getCollaborators() { |
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.
I would prefer to keep the callback here vs returning a promise
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.
Okay, but I wonder what the reason for this is?
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.
It is strictly preference. I prefer nodebacks over promises. :]
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.
Fixed. PTAL!
const body = comment.querySelector('.comment-body') | ||
if (body && LGTM_RE.test(body.innerHTML)) { | ||
const paragraphs = comment.querySelectorAll('.comment-body > p') | ||
if (Array.from(paragraphs).some(p => LGTM_RE.test(p.innerHTML))) { |
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.
just curious, what's the reason for this change? I find this a lot more difficult to read than the previous implementation.
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.
In nodejs/node#10657, a LGTM embedded in a <blockquote>
(and therefore one that does not belong to the author of the comment) was recognized. This piece of code only looks for direct <p>
children of .comment-body
, and mitigates that issue.
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.
ah cool that makes sense.
- Make regex static and more concise - Iterate over RE.exec - Use Map
Thanks! |
Bug fixes:
#
fragmentsAlso some internal simplifications of RegExps, Promises, Maps, etc.