I haven't fully reviewed the code yet, so I can't approve it on GitHub. However, I'd like to express my personal opinion on this approach.

I am in favor of this approach.

From my experience, template literals often contain sentences in natural language. Therefore, I believe it's hard to determine the format of expressions within template literals solely from AST.

Ideally, we wouldn't want to introduce a format that depends on user-input line breaks. However, I think this is acceptable.

If we decide to accept this PR, we'll need to update https://prettier.io/docs/en/rationale.html.

I've gone ahead and updated the rationale (and the changelog).

Does anyone have opinions on whether we should still keep the old "sufficiently simple" heuristic, or just rely on the "is there a linebreak" thing?

Is the current heuristic really hopeless? Or can it probably just be updated to cover cases like format(data)?

I don't think the current heuristic is salvageable. As @sosukesuzuki points out, the fundamental problem is that the appropriate formatting depends on the content of the template string, which is just not something it's practical for Prettier to reason about.

It's not just stuff like format(data) - consider console.log(`you have ${n} new message${n === 1 ? '' : 's'}.`), for example. That definitely shouldn't be split over multiple lines. But to know that you have to know that it's prose, such that a linebreak would make it unreadable; if the thing being printed were something else, a linebreak might well be acceptable. And I don't think any purely AST-based heuristic is going to be able to figure that out.

Rebased. Friendly ping for maintainers - can we get this merged?

I hate that prettier mangles template literals, but I have a question about your implementation. You state that you won't add linebreaks in this example:

let items = `
  ${someComplicatedExpression()}
  ${someComplicatedExpression()}
`;

But that expression would already not be split or kept as one line because prettier only splits up a line when the line break occur within a sub expression ${} as there is a functional different between \ncontent\ncontent\ncontent and content content. In your first example you correctly enumerate this. I guess with that... I'm just a bit confused on what's changing here?

I hate that prettier mangles template literals, but I have a question about your implementation. You state that you won't add linebreaks in this example:

let items = `
  ${someComplicatedExpression()}
  ${someComplicatedExpression()}
`;

But that expression would already not be split or kept as one line because prettier only splits up a line when the line break occur within a sub expression ${} as there is a functional different between \ncontent\ncontent\ncontent and content content. In your first example you correctly enumerate this. I guess with that... I'm just a bit confused on what's changing here?

Suppose someComplicatedExpression() was really long, exceeding the print width, and also had an opportunity for a line break. Right now (prior to this PR), Prettier will put in linebreaks inside the ${}, like in this playground:

let items = `
  ${someComplicatedExpression(
    asdf,
  )}
  ${someComplicatedExpression(
    asdf,
  )}
`;

With this PR, it won't anymore; it just leaves the input alone, like this:

let items = `
  ${someComplicatedExpression(asdf)}
  ${someComplicatedExpression(asdf)}
`;

Does that answer your question? If not I don't understand your question.

@bakkot It perfectly answers my question. That makes total sense, if the user has a line break within the sub expression within a template string, it will format it nicely... if no line breaks, it doesn't touch it. I played around with it and it behaves like I would expect, which is leaving my template strings alone.

@sosukesuzuki Any chance we could look at this PR again? It's a blocker in our teams adopting prettier and from the checks above it seems to be mergeable pending review.

@fisker Can you review this?

@sosukesuzuki Is it possible to land this without @fisker's review? This has been ready for four months.

@sosukesuzuki @fisker ping?

I'm deeply sorry for the long delay.

Sometimes respects the original line break is annoying, when I delete props from object literal, I don't know if it can fit one line, I often have to delete new line after { before Prettier runs, especially when there are only 2~3 properties left.

Anyway, I agree curenttly we format the template literals really bad in some cases, I'll just remain neutral on this one.

@thorn0 also seems not happy with this solution, #15209 (comment)

What about template literals like `${ ... }px`? Code like that is widespread because of the prefer-template ESLint rule. Keeping everything on one line feels unexpected here:

Prettier pr-15209
Playground link

Input:

let items = `${someComplicatedExpression(asdf) + cantileveredRhinocerosFactory / someComplicatedExpression(asdf) - transdecimalThingamabobProvider}px`;

Output:

let items = `${someComplicatedExpression(asdf) + cantileveredRhinocerosFactory / someComplicatedExpression(asdf) - transdecimalThingamabobProvider}px`;

It's not just stuff like format(data) - consider console.log(`you have ${n} new message${n === 1 ? '' : 's'}.`)

That's a convincing example. But what about longer expressions, those that are longer than printWidth? Would it really ever make sense from the readability point of view to keep those long expressions on a single line?

In my experience it people overwhelmingly prefer not to have linebreaks within an interpolation, even if the interpolation is long.

So I think the right default is to not introduce any linebreaks and allow users to opt in where it makes sense to do so by adding one, instead of trying to have a more complicated rule. I'm open to more complicated rules if you want to suggest them, but I think there's a lot of value in simplicity.