This also changes single-step ternaries, i.e.

mySuperDuperExtraLongTernary
  ? "yes"
  : "no"

becomes

mySuperDuperExtraLongTernary ?
  "yes" :
  "no"

and … I really really like the current placement of ? / :.

I'm OK with this proposal for multi-step ternaries, but then that'd be inconsistent.

My 2¢.

@hawkrives that was intentionally done, since the convention for other operators is to keep the operator at the end of the line instead of the beginning when breaking. Ternaries were the odd one out here. I assumed that consistency would be desired.

It'd be easy enough to account for non-nested ternaries and keep the old behaviour of placing the operators at the beginning of the line, I don't mind doing it, but how do I know what the Prettier maintainers decide?

Someone should create a poll for the preferred format. I think having the operators at the beginning of the line is much more readable, but there were a handful of competing formatting suggestions in #737.

Personally not a fan of this style (in large part because it seems very much out of keeping with how most people write JS), especially for non-nested ternaries, but that aside, one thing:

aaaaaaaaaaaaaaa ?
  bbbbbbbbbbbbbbbbbb :
ccccccccccccccc ?
  ddddddddddddddd :
eeeeeeeeeeeeeee ?
  fffffffffffffff :
gggggggggggggggg;

why is the gggggggggggggggg not indented? That seems really odd, to my eye, since gggggggggggggggg is a value like b / d / f and not a condition like a / c / e.

It is not indented because it is the form of the proposal suggested in #737 (comment). There was no clear direction or expressed preference for a specific proposal in that thread from Prettier maintainers, so I implemented the one that I felt had the most merit.

As to why I personally like the final value to be dedented, it's because it's like a default case in a switch statement. It's the value of the entire expression when none of the tests match. Not dedenting it makes it seem like it's related only to the last test when it's related to all the tests.

Having said that, I'm not dead-set on dedenting the ultimate alternate expression (nor the trailing operators), primarily I want to get rid of the stepped nesting for alternate expression nesting.

I've never seen ternaries formatted like this before. At first glance I was disturbed but then I realized it makes sense, it's consistent and actually very readable. I think I like it!
Splendid work @zeorin!

I think this style is too significant of a change. If nothing else, we shouldn't change the way non-nested ternaries format.

I do think this style has the most merit, in addition to the points raised by @0x24a537r9 in #737 (comment):

• operators at the end are easier to work with when maintaining the code, needing less nit-picky moving around of operators (which, admittedly, use of Prettier-on-save can obviate), and thus also leading to less noise in VCS diffs (much like trailing commas in multiline object & array literals).

Myself, I wasn't a fan of this proposal at first, either, but over time it grew on me, on the strengths of its merits. (Incidentally, I went through the same process when I first encountered trailing commas.)

I personally think that changing non-nested ternaries to be consistent with nested ternaries is more important than some one-time mental friction of getting used to the new style (especially as it would be consistent with operators in general, not just the nested ternaries).

Having said that, I mostly care about removing the "infinite stairs" for alterate sub-expression ternary nesting and the other details of the style don't matter nearly as much.

I'm happy to make changes to whatever style is settled on, but at this point this thread is suffering from the same bike-shedding as #737 was. I was hoping that shipping some actual code of an implementation would act as a sort of Occam's Razor and we could move on.

This means that I'm not sure what to change, as whatever I change it to, someone will have issue with. Who knew that ternary style preferences are so diverse?

Anyway, I think we need to make a decision on what style we go with, and to that end, @vjeux, please will you make a call?

I think we should experiment with a style that causes as little change as possible to maximize the chance of moving forward. So don’t move the ? and :. Just flatten the indentation (when it makes sense). Optimize for the common case.

type TypeName<T> = T extends string
  ? "string"
  : T extends number
  ? "number"
  : T extends boolean
  ? "boolean"
  : T extends undefined
  ? "undefined"
  : T extends Function ? "function" : "object"

I'm gonna implement @lydell's proposal this weekend and make a PR.

Edit: Well, I obviously didn't get to that last weekend. I'll do it this weekend, instead

Removing my assignment because I intended to assign myself to the issue, not the PR.

@zeorin many 👍s on this.
How will this work for cases like #4199 #4874 #4979 ?

@thgreasi I don't intend to change that behavior as part of this. That is intended behavior; please comment on one of those issues if you have input.

Fixed in #5039.

Whilst I'm glad that this issue is now fixed (:tada:), It's regrettable that there was no direction from the maintainers on this PR.

There was a lot of discussion, sure, by many people, but not one maintainer saying something like: "Please tweak foo, bar, and baz, and then it's good to merge".

The barrier to entry on making this PR was pretty high. I read the original paper to get a sense of how Prettier works, and spent a whole weekend coming up with the first draft of the PR, tweaking it a bunch over the following days.

That effort was wasted.

I urge the Prettier maintainers to be more forthcoming and transparent.

@zeorin I'm sorry that you didn't have the best experience here.

This particular issue has been long standing and is likely one of the oldest issues still opened. The reason is that we needed to decide on the way we wanted to print this piece of syntax. Your PR has actually been critical to get the discussion started again and it finally drove to a final decision.

About the actual implementation, it's a bit unfortunate that we created a new PR rather than asking you to update yours. There are two reasons for this:

• The eventual design was different than the one you suggested and it wasn't immediately obvious that code could be shared.
• The actual implementation has never been an issue in this case. This is a very simple change for anyone that has already contributed to prettier. So it only took something like 5-10min to spin up the PR and it would have likely taken an order magnitude more time to teach you how to morph your PR into the final one.

Thanks for raising this issue and I hope that this gives you some insight around why things happened this way. But please remember that your PR was not useless, this long standing bug has been closed now because of you.