-
-
Notifications
You must be signed in to change notification settings - Fork 34.2k
Refactor functions to arrows #4796
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
|
LGTM pending CI |
|
LGTM |
|
ARM CI failure is unrelated. I re-ran the linter again since there was a Jenkins failure with it the first time: https://ci.nodejs.org/job/node-test-linter/1004/ LGTM |
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.
Do we have a defined code style on parens for single argument arrow functions?
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 don't think we have one. The eslint rule would be http://eslint.org/docs/rules/arrow-parens.html
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'm happy either way, just wanted to bring it up. :)
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'd like to see us specifying these sort of things in one clear way (of course, I don't mind aligning with it).
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.
Please can we go for always-parens around the arguments when we do these? I find the terseness without them make them harder to visually parse when reading code. I think I might have @cjihrig on my side on this at least.
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'm perfectly fine with either (both are readable IMO) but I definitely something that thing should be specified clearly in a coding styleguide.
Refactor a bunch of `function(...){ return ... }` into `(...) => ...`.
PR-URL: nodejs#4796
Reviewed-By: Brian White <mscdex@mscdex.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: thefourtheye <thechargingvolcano@gmail.com>
|
Thanks for the review. Ready to land. |
|
-1. exporting arrow functions should be a major |
|
@vkurchatkin ... I tend to agree but can you expand on the reasoning for that |
|
In fact, reviewing it further, I'm going to pop the LTS watch label off this... |
I agree, The context of this can not be changed with |
|
going to mark as semver-major defensively for now. That shouldn't stop it from landing tho if we think it's ready :-) |
|
I'm going to close this - I wanted to start discussion about the coding style in the files - look like that goal has been achieved. As we don't have a consensus that arrows are a good idea here I'm going to close this. (The concerns for a breaking change are unfounded though - the function doesn't use |
Another really small one, refactor a bunch of
function(...){ return ... }into(...) => ....I considered also changing
Clientand removing theself = thisbut as itis a legacy interface I don't think it's worth the trouble.