Skip to content

Conversation

@thorn0
Copy link
Member

@thorn0 thorn0 commented Mar 18, 2020

Supersedes #7782
Fixes #4124
Fixes #6122
Fixes #7775
Fixes #7686

  • I’ve added tests to confirm my change works.
  • (If changing the API or CLI) I’ve documented the changes I’ve made (in the docs/ directory)
  • (If the change is user-facing) I’ve added my changes to changelog_unreleased/*/pr-XXXX.md file following changelog_unreleased/TEMPLATE.md.
  • I’ve read the contributing guidelines.

Try the playground for this PR

const v2 = /** @type {}} */ (value);
const v3 = /** @type } */ (value);
const v4 = /** @type { */ (value);
const v5 = /** @type {{} */ (value);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should ignore it and keep as is

Copy link
Member Author

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 should. We might try checking the syntax of types in these simple cases, but what about more complex ones? Those types can contain everything, e.g. curly braces inside quotes.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's what I mean:

const curly = /** @type { '}' | '{' | '}}' } */ (getCurly());

Copy link
Member Author

@thorn0 thorn0 Mar 18, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, as I wrote in comments in the code:

TypeScript expects the type to be enclosed in curly brackets,
however Closure Compiler accepts types in parens and even without any delimiters at all.
That's why we only check that there is at least one non-whitespace character after @type.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sound reasonable, but on the other hand we can add unnecessary parens when somebody has @type in comments, yes, it is edge case, let's keep it as is, if somebody open a issue about it we will improve it

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a very edge case. One has to have both @type in a comment AND a parenthesized expression after that comment.

Copy link
Member

@alexander-akait alexander-akait left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks very very very good, can we list of fixes issues?

@thorn0 thorn0 force-pushed the closure-type-casts branch from 43ad2a9 to 6b12525 Compare March 18, 2020 16:58
}
}

function removeJsDocAsterisks(commentValue) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't find a test case that actually requires this. I think the intention is to exclude leading * after a newline after the @type annotation? If so, I think it'd be plenty fine to just search for @type and not care about having a non-whitespace char.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree. This is leftover code from the check for curly braces around the type.

}
});

visitNode(ast, node => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could probably do this in a single walk, since the ancestor will have been visited first.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it won't.

Comment on lines +33 to +39
const { expression } = node;
if (!expression.extra) {
expression.extra = {};
}
expression.extra.parenthesized = true;
expression.extra.parenStart = node.start;
return expression;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about open a issue in babel repo about it? I think they can improve, we have pretty good reasons for this

Copy link
Member Author

@thorn0 thorn0 Mar 19, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see what you mean. Creating this extra stuff is Babel's default behavior, but it's not created when createParenthesizedExpressions is on. However, some other code in Prettier relied on extra.parenthesized , so I couldn't just enable createParenthesizedExpressions without recreating extra.

@thorn0 thorn0 force-pushed the closure-type-casts branch from 32b74d2 to 875dc1d Compare March 19, 2020 10:33
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants