This is the blocker to use Babel in our project.
I want to avoid to use forked Babel because it's a very painful so please consider this PR🙏

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/6314/

My concern with this any time is comes up is that to define an API that we can confidently maintain, we need to know what we are guaranteeing. If a random plugin decides to clear node.extra and the parens vanish, how are users supposed to know what happened, for example? Or if we replace the node being cast with another node, none of our current logic preserves .extra. Moreover, any existing plugin could introduce a new piece of code to cause that in the future, and I wouldn't consider it a breaking change currently, but with this flag enabled, any change like that could qualify as a breaking change.

For example if a user does

import foo from "bar";

var other = /** ... */(foo);

and we transform that to

var _bar = require("bar");

var other = _bar.default;

the foo AST node is just gone, and the member expression has no .extra.

@loganfsmyth Thank you for your feedback!
I've added a commit to reach out your concern.

I thought comments also have the same problem but comments are passed from an oldNode to a newNode so I've applied it to parens as well as comments.
Does it make sense?

The issue with emulating comments is that we already don't make any guarantees about comments. Babel is only defined to make a best effort at preserving comments, because comments have no functional affect on runtime code, and people already run into issues with that. They'd likely have the same issues with this, so we'd be introducing a new thing for people to trip on.

To do this "right" given our current structure, we'd have to have an actual AST node for parenthesized expressions, and then every single transform we and anyone else writes would have to make sure to handle it, which would be a mountain of work for everyone involved.

@loganfsmyth
Thank you!
From my perspective, this implementation could cover many cases even though there are no guarantees as you've pointed out.
Do you have any issues or examples for that?
(BTW, extraParens might be a better name than retainParens as an option name)

I think it's hard to guarantee to work this well against any AST operations.
But I could cover more cases.
Doesn't it make sense to fix the problems at the same time with comments in later?

Is having an actual AST node for Parens(ParenthesizedExpression?) the only way to add this feature?
If so, I'll work on this.

I've updated this to remove the option from babel-core and rename the option name to retainExtraParens.

I'm running into this as well. Removing the parens should really be up to babel/minify.

I believe retaining the parens through the transformation passes is always the right thing to do.

Maybe the option should be called printAllParens or printExtraParens.

I want us to make progress on this. Here is my proposal:

• Create a new PR that contains the code to inheritParens so that the parens are not lost in transformations. (This should be non controversial)
• After that we can go a few ways:
  • Add a flag to print extra parens?
  • Always print extra parens after a /** */ comment (when printing comments)?
  • Add a closure compiler flag?

@koba04 @loganfsmyth WDYT?