fix: Format Intersection same as Union

[albertorestifo]

Share the same logic to format Interection and Union types in TypeScript
and Flow.

Closes #3986

[j-f1]

Awesome! LGTM, but I’d like to hear what other maintainers think about it.

[vjeux]

As a general rule, if there's complexity in prettier, it probably means that it's there for a reason and we didn't just do it for fun.

For more context, having | be leading was already controversial, as the most common style from what I could tell was to make it trailing. We went through it because it made it line up nicely.

But for &, I've never actually seen people write it in a leading fashion. One of the big reason why is that you very infrequently have to chain them. & is there to build a bigger type, so you usually have one base type and one literal {}.

Worse case is that you will have multiple variables that you chain with one literal. This one isn't super pretty right now but okay and not the common case.

I'm curious do you have a real example that motivated this? In the issue it's just made up code.

[vjeux]

It looks worse to me

[vjeux]

This is the only one that is arguable, but in my experience it's rare that you combine two variables with an object

[suchipi]

I much prefer the current behavior

[azz]

Strongly prefer the inline version and agree with @vjeux's comments.

[j-f1]

How about inlining (for both operators) an identifier/member expression at the beginning xor at the end? i.e.

type foo = Foo & {
  bar: Baz
}

type bar =
  & Foo
  & Bar
  & {
      baz: Quux
    }

[albertorestifo]

A real-world example of when this formatting comes in handy, is when combining React HOC in a GraphQL-Apollo app, where I needed to construct a type combining many verbose types:

// When creating an HOC
type Props = Subtract<InputProps, WithURLStateProps> &
  RouteComponentProps<ProjectViewRouteParams>;

// A component that uses many HOC
type WithMergeIntentsMutationProps = WithAddIntentToClassifierProps &
  MergeIntentsProps &
  RouteComponentProps<ProjectViewRouteParams>;

Playground

It might not be a common use case, but the formatting proposed in this PR makes this scenario much easier to read IMO.

I like the solution proposed by @j-f1

[vjeux]

Thanks for the concrete use case. This is the case where it's indeed debatable as to which is the best way. I've personally never seen anyone write those with a leading & in the past. It also feels confusing to me: if there's a space after &, it looks like a binary operator but there's nothing before the first one.

Not sure how involved it would be to implement but adding a newline after = in this case may not be a bad solution:

// A component that uses many HOC
type WithMergeIntentsMutationProps =
  WithAddIntentToClassifierProps &
  MergeIntentsProps &
  RouteComponentProps<ProjectViewRouteParams>;

In any case, I'm reasonably happy with the current output and don't think that we should drastically change it.

[j-f1]

How do we feel about adding some heuristics to avoid breaking in some cases (for example, in Foo & { ... }) and merging this?

[vjeux]

@j-f1 we already shouldn’t break for

type A = Foo & {
  a: int
};

[j-f1]

We do, however, break for multiple identifiers:

Prettier 1.12.1
Playground link

Input:

type A = Foo & Bar & Baz & {
  a: int
};

Output:

type A = Foo &
  Bar &
  Baz & {
    a: int
  };

[albertorestifo]

I'll close this as inconclusive