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
JavaScript: Keep comments position for assignment/variable #7709
Conversation
@@ -69,3 +69,6 @@ const style2 =/** | |||
const v6 = /**@type {string} */(value); | |||
const v7 = /** @type{string} */(value); | |||
const v8 = /**@type{string} */(value); | |||
|
|||
const v9 = /** @type {string} */ | |||
(value); |
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.
Maybe for @type
comments (for all JSDoc comments) better to keep it in one line
/cc @thorn0
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.
Yeah, why not do this for all comments?
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.
Looks good. I'll fix.
// Input
const foo = /* foo */
bar;
// Expected output😄
const foo = /* foo */ bar;
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.
done!
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.
Looks very good!
Besides, multiple comments inside assignments behave strangely: Prettier pr-7709 --parser babel Input: var a = /*1*/ /*2*/ /*3*/
// 4
x;
var a = /*1*/ /*2*/ /*3*/
x;
var a = /*1*/ /*2*/ /*3*/
/*4*/
x; Output: var a /*1*/ /*2*/ =
/*3*/
// 4
x;
var a /*1*/ /*2*/ = /*3*/ x;
var a /*1*/ /*2*/ =
/*3*/
/*4*/
x; |
src/main/comments.js
Outdated
contents, | ||
hasNewline(options.originalText, options.locEnd(comment)) ? hardline : " " | ||
]); | ||
const leftNode = |
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.
Can we probably just use Checked that, turns out comment.precedingNode
here instead of leftNode
?precedingNode
is already deleted when this function is called.
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.
How about making this solution more general:
const lineBreak = hasNewline(options.originalText, options.locEnd(comment))
? hasNewline(options.originalText, options.locStart(comment), {
backwards: true
})
? hardline
: line
: " ";
?
I see this breaks some tests, but let's discuss those cases. Maybe this behavior is okay for them too.
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.
Input:
if (foo) /* baz */
bar();
if (foo)
/* baz */
bar();
Current output:
if (foo)
/* baz */
bar();
if (foo)
/* baz */
bar();
Output with my proposed change:
if (foo) /* baz */ bar();
if (foo)
/* baz */
bar();
I would say it's okay to do this. If the user wants this comment to be on the next line, they can move it manually, and it will stay there.
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.
@thorn0 Thank you! I did not know backwards
option. Could you tell me what does that 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.
It determines the direction, in which hasNewLine
searches for a new line. By default, it searches the source code forward from the given index. With backwards: true
it searches backwards.
hasNewline(options.originalText, options.locStart(comment), { backwards: true })
This returns true
if there is a new line between the comment and the last non-whitespace character before the comment.
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.
Would be good to hear from @evilebottnawi or @j-f1 if they're okay with this change.
Looking at the snapshots, I found some changes that don't look good to me: Input: const kochabCooieGameOnOboleUnweave = // ???
annularCooeedSplicesWalksWayWay;
const bifornCringerMoshedPerplexSawder = // !!!
glimseGlyphsHazardNoopsTieTie +
averredBathersBoxroomBuggyNurl -
anodyneCondosMalateOverateRetinol; Prettier 1.19.1 Output: const kochabCooieGameOnOboleUnweave = annularCooeedSplicesWalksWayWay; // ???
const bifornCringerMoshedPerplexSawder = // !!!
glimseGlyphsHazardNoopsTieTie +
averredBathersBoxroomBuggyNurl -
anodyneCondosMalateOverateRetinol; Prettier pr-7709 Output: const kochabCooieGameOnOboleUnweave =
// ???
annularCooeedSplicesWalksWayWay;
const bifornCringerMoshedPerplexSawder =
// !!!
glimseGlyphsHazardNoopsTieTie +
averredBathersBoxroomBuggyNurl -
anodyneCondosMalateOverateRetinol; |
I propose the following implementation of function handleVariableDeclaratorComments(
enclosingNode,
followingNode,
comment
) {
if (
enclosingNode &&
(enclosingNode.type === "VariableDeclarator" ||
enclosingNode.type === "AssignmentExpression") &&
followingNode &&
(followingNode.type === "ObjectExpression" ||
followingNode.type === "ArrayExpression" ||
followingNode.type === "TemplateLiteral" ||
followingNode.type === "TaggedTemplateExpression" ||
isBlockComment(comment))
) {
addLeadingComment(followingNode, comment);
return true;
}
return false;
} |
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.
Looks good now. Please add the snippet from #7709 (comment) to the tests.
@evilebottnawi @j-f1 Could you review again? |
Sorry, this is not related to 2.0
Fixes #6120
Currently, the use of almost expressions in assignments/variable-declarations containing BlockComment move the position of the comment to before
=
. The behavior also break the Closure Compiler type casting comments(ref :#4124 (comment)).This PR fixes the behavior by making it consistent with array, object literal and template literal.
changelog_unreleased/*/pr-XXXX.md
file followingchangelog_unreleased/TEMPLATE.md
.✨Try the playground for this PR✨