-
Notifications
You must be signed in to change notification settings - Fork 21
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
Modernize code with a stricter lint config #111
Conversation
Until now, all the changes only affected the style and not the behavior of the code. The rest of the rules require (minimal) code behavior changes, so perhaps it's best to track them in a separate PR to avoid losing them in the sea of whitespace changes. This is the list:
I can temporarily disable these rules in this PR, and then fix them in a successive PR |
I agree with your reasoning! |
Ok, I'll finish this up and then I'll work on the rest later |
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 tested this and it still works; I reviewed the code and it looks like all changes are stylistic only (i.e. the behavior didn't change), except the following
src/githubFactory.js
Outdated
// Transform a github function call into a queued function call | ||
// to ensure that only one API call runs at a time | ||
// https://developer.github.com/guides/best-practices-for-integrators/#dealing-with-abuse-rate-limits | ||
const qd = call => { |
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.
FYI I hope to replace this in a future PR; I think p-queue can replace both qd
and the queue
module while also helping a possible (internal) promisification of remove-github-forks
. Callback hell can be avoided nowadays
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 fully support that.
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.
We’re on Node, so util.promisify can help transition a lot of these without rewriting everything in one go.
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.
Thanks for the effort!
console.log(" Create a token with permissions public_repo, delete_repo"); | ||
console.log(" Pass that in the CLI, enjoy!"); | ||
console.log(""); | ||
program.on('--help', () => { |
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.
Here and in other similar places, is the function(){}
syntax being replaced by () => {}
automatically by xo or by you manually?
If automatically, I don’t mind much, just surprised to see. If manually by you, I don’t mind much, but I don’t see much benefit in that effort.
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.
XO does this automatically with eslint’s prefer-arrow-callback
but
- For some reason it’s being ignored when run with Prettier (it’s not a conflicting style)
prefer-arrow-callback
is unset by Prettier xojs/xo#498 so I used Lebab to do the conversion until that bug is fixed - In many cases it’s shorter and cleaner, e.g.
a.map(function (b) {
return b.data;
});
// versus
a.map(b => b.data);
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, prefer-arrow-callback
, thanks for telling me. Let’s keep the xo default.
Of course they’re nice with short functions with implicit returns, but for longer functions, they do not save space, but add two more punctuation chars. ¯\_(ツ)_/¯
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.
but for longer functions, they do not save space
I don't think that ever happens, do you have an example?
() => {return a}
// Is always shorter than
function () {return a}
The only difference is in declaration vs expression:
function a () {}
const a = () => {}
for which I agree with you and hasn't been touched by this PR because I think there weren't any declarations.
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.
We’re (presumably) not saving bytes, we’re saving visual noise that costs attention span. In that regard, list.map(item => item * 2)
is by far better (has less visual noise) than list.map(function(item){ return item * 2; })
. The same is not the case for multiline functions. In the example below, in my opinion, the version with the keyword is less visually noisy due to the keyword being more distinct and atomic than the ASCII art arrow:
addEventListener("click", function(event){
// ...
});
addEventListener("click", (event) => {
// ...
});
This becomes increasingly problematic in very nested expressions due to the likelihood of the arrow syntax being more similar to other js operators and syntaxes:
foo <= bar ? quux / 3 : f(function(){
// perform operations
});
foo <= bar ? quux / 3 : f(() => {
// perform operations
});
This is all subjective, so I don’t mean to speak the final word, just explaining what I mean.
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 see what you mean. Many functions/callbacks will be gone in my promisification though, so it won't be much of a problem either way. ✌️
When you’re done with the branch, let me know, I’ll gladly rebase it. (I don’t prefer squashing unrelated changes together) |
I'm done! |
OT: I have great news. I promisified it partially and brought down the run time from 1m10s to 10s by using the native throttler |
Ended up only having two commits due to the big dependencies between the various changes. Thanks for this, modernizing this is beneficial for future maintenance! Also, great news about the throttler! remove-github-forks was always a bit slowish, maybe that’ll change. |
Preview PR as described in #108 (comment). So far it's not very interesting, it's just eslint and Prettier cleaning things up.
Once that's merged, I'll revert the
demo
commit and re-fix the new code automatically.A few more manual changes will also have to be applied on the next step: