Proposal: ParenthesizedType

[k2snowman69]

This proposal is to add a parenthesis type for expressions. This was slightly mentioned in the CST issue but I think this is much more basic, hence splitting it out into it's own issue.

Issue

Note: yes this is very contrived and will always result in the same value but it's trimmed down for this example:

let value = (2) | 1;

The trimmed down output of this without a parenthesized type is:

{
    type: "BinaryExpression",
    range: [12, 19],
    operator: "|",
    left: {
      type: "Literal",
      range: [13, 14],
      value: 2,
      raw: "2"
    },
    right: {
      type: "Literal",
      range: [18, 19],
      value: 1,
      raw: "1"
    }
  };

which means the context of the parenthesis is missing. This means if you were to reprint this document, you have no context as to where a user may or may not have added parenthesis to break up expressions.

For me, I'm writing a cli that helps order code so losing the context of the parenthesis means that my code now reorders this binary expression like this

let value = (1) | 2;

Which isn't what the developer initially intended

Proposal

Adding a ParenthesizedType will allow for the context of the parenthesis to be conveyed in the AST

{
    type: "BinaryExpression",
    range: [12, 19],
    operator: "|",
    left: {
      type: "ParenthesisExpression",
      range: [12, 15],
      raw: "(2)",
      value: {
        type: "Literal",
        range: [13, 14],
        value: 2,
        raw: "2"
      }
    },
    right: {
      type: "Literal",
      range: [18, 19],
      value: 1,
      raw: "1"
    }
  }

Credit to where credit is due, I got this idea from TSParenthesizedType from typescript-estree

[Meir017]

is this related to the following scenario?

(fn1) = function(){}
fn2 = function(){}

viewing this in astexplorer.net shows identical trees for both

[k2snowman69]

Yep, exactly. These two trees should not be identical and instead for the left identifier there should be a ParenthesizedType

[Meir017]

related babel issue recently fixed - babel/babel#14514
babel has an extra property on node objects where this metadata is saved
from the PR -