Prettier pr-16500
Playground link

--parser babel

Input:

(getConsoleLog?.())``

Output:

getConsoleLog?.()``;

Second Output:

SyntaxError: Tagged Template Literals are not allowed in optionalChain. (1:1)
> 1 | getConsoleLog?.()``;
    | ^
  2 |

In addition to the case you mentioned, i considered a few more exceptional cases.

Moved to shouldAddParenthesesToChainElement ac50078

There are two other cases need to fix.

(a?.b)!``;

(a?.b!)``;

Can you try to fix them?

There are two other cases need to fix.

(a?.b)!``;

(a?.b!)``;

Can you try to fix them?

Okay. I will try this.

@fisker
I have added exception handling.
But there are many cases (about 3) and it's too complicated to remove the duplication.
Would this implementation be okay now?

Looks good, I'll take another look later.

Please add a changelog entry https://github.com/prettier/prettier/blob/main/CONTRIBUTING.md#pull-requests

I added changelog. But what should I do about duplication error in lint? Should I combine js and ts changelog?

@syi0808

Looks like I found 4 cases that failed

((a?.b!)())``;
((a?.b)!())``;
((a?.())!())``;
((a?.()!)())``;

But should not related to tagged template literals.

Prettier pr-16500
Playground link

--parser babel-ts

Input:

(a?.b!)()

Output:

a?.b!();

This is wrong, it changed the call to optional chainning.

But we format

(a?.b!).c

correctly, so we missed some checks for babel parser, can you try to fix? (Can be separate PR, since it's different case)

Maybe it's here

Also, can you move these tests to chain-expression? Because I feel we are doing things wrong in for the NewExpressions too, we need the same tests for NewExpressions, after this get merged.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Optional_chaining#invalid_optional_chaining

correctly, so we missed some checks for babel parser, can you try to fix? (Can be separate PR, since it's different case)

Separating PR may reduce the scope of work and make it easier to manage, but this actually seems to be handling with the exception of chain expression not only related to tagged template literals. I'll fix it soon.

Also, can you move these tests to chain-expression? Because I feel we are doing things wrong in for the NewExpressions too, we need the same tests for NewExpressions, after this get merged.

I'll move test. and we can also move new expression also into chain expression in this pr?

But should not related to tagged template literals.

Prettier pr-16500 Playground link

--parser babel-ts

Input:

(a?.b!)()

Output:

a?.b!();

This is wrong, it changed the call to optional chainning.

But we format

(a?.b!).c

correctly, so we missed some checks for babel parser, can you try to fix? (Can be separate PR, since it's different case)

I modified existing implementation it to cover this.

we can also move new expression also into chain expression in this pr?

Let's not make this huge. We don't know what we will face. I'm going to merge this first.

Would like to continue work on this?

In next PR, we duplicate tests in this PR. And change

For NewExpression

- ... ``;
  new ...;

For MemberExpression (second one make sure we checking .object not .property)

- ... ``;
  ... . foo;
  foo [...];

For CallExpression (second one make sure we checking .callee not .arguments)

- ... ``;
  ... (foo);
  foo(...);

Would like to continue work on this?

In next PR, we duplicate tests in this PR. And change

For NewExpression

- ... ``;
  new ...;

For MemberExpression (second one make sure we checking .object not .property)

- ... ``;
  ... . foo;
  foo [...];

For CallExpression (second one make sure we checking .callee not .arguments)

- ... ``;
  ... (foo);
  foo(...);

Thank you for organizing. I'll research this and submit PR soon.

After we add/fix all tests.

We need rewrite the existing logic, currently it's a mess.

The logic should be:

1. Check if it's root element of ChainExpression (Need two version, one for babel, one for estree)
2. Skip TSNonNullExpession
3. Check if it's TemplateLiteral.tag / NewExpression.callee / CallExpression.callee / MemberExpression.object

This can be done in the followup PR.