Allow keeping parenthesis for closure compiler type casting

[stringham]

When writing javascript for use with the Closure compiler, parenthesis directly following a type annotation comment have meaning.

Type cast precede a parenthesized expression.

var x = /** @type {string} */ (fruit);

prettier outputs:

var x /** @type {string} */ = fruit;

[vjeux]

We're not doing a good job at respecting all those comments. We also have a bunch of issues with flow comments.

[bakkot]

@vjeux It's not just that the comment is moved; Closure is treating the parentheses as semantic, and will give a warning if they're dropped. (Ugh.)

[DrRataplan]

Thanks a bunch for addressing this, I found one oversight though.
When using an inline type cast, like this:

const charCode = /** @type {string} */ (fruit).charCodeAt(0);

prettier outputs

const charCode = /** @type {string} */ (fruit.charCodeAt(0));

The workaround is easy though: just move the cast to a different statement, like this:

const strFruit = /** @type {string} */ (fruit);
const charCode = strFruit.charCodeAt(0);

or add additional parentheses:

const charCode = (/** @type {string} */ (fruit)).charCodeAt(0);

[roelkok]

This doesn't seem to work for me. It should work without setting a specific option, right?

a.) /** @type {MeshBasicMaterial} */(this.plane.material).map.needsUpdate = true;

Gets rewritten to

b.) /** @type {MeshBasicMaterial} */ this.plane.material.map.needsUpdate = true;

And if I do this

c.) (/** @type {MeshBasicMaterial} */ (this.plane.material)).map.needsUpdate = true;

It gets rewritten to a. on the first save and eventually to b. on the second save.

I'm using the 'Prettier - Code formatter' extension for VS Code.

[j-f1]

@roelkok That sounds like a bug. Can you open a new issue and fill out the template please?

[roelkok]

Opened an new issue here #4124