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.
Do we have a defined code style on parens for single argument arrow functions?
There was a problem hiding this comment.
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.
I'm happy either way, just wanted to bring it up. :)
There was a problem hiding this comment.
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.
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.
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.