Inconsistent formatting between long function param and long type param

[yukukotani]

Prettier 2.2.1
Playground link

--parser babel

Input:

const LongVar = LongLongLongLongLongFun(param, { 
  key1: "value1"
});

type LongType = LongLongLongLongLongLongType<Param, {
  key1: Value1,
}>

Output:

const LongVar = LongLongLongLongLongFun(param, {
  key1: "value1",
});

type LongType = LongLongLongLongLongLongType<
  Param,
  {
    key1: Value1,
  }
>;

Expected behavior:

The output should be same as input I think.

const LongVar = LongLongLongLongLongFun(param, { 
  key1: "value1"
});

type LongType = LongLongLongLongLongLongType<Param, {
  key1: Value1,
}>

[thorn0]

Not sure this needs to be changed. At least, it's definitely not a "bug". It's very common to format function calls this way, so Prettier has a lot of complexity around formatting function calls to reflect these common practices. I'm not convinced it makes sense to add that complexity to the code that prints type arguments.

[yukukotani]

Agree that this is not a bug. I feel this format is also common in type params and it should be consistent between function call and type params.
But I understand the Prettier's philosophy, so no need to change if this is just my preference.

[thorn0]

I feel this format is also common in type params

Links to projects that use this style would be helpful.

Function calls themselves can have type arguments too. Does this look good?

longLongLongLongLongLongType<Param, {
  key1: Value1,
}>(param, { 
  key1: "value1"
});

[kbrilla]

same happens in class declarations and it really looks bad
Happens after upgrade form 2.2.1 -> 2.3.2

[brodybits]

same happens in class declarations and it really looks bad

I just made a playground to help investigate this (don't think which parser will make any difference):

Prettier 2.3.2
Playground link

--parser babel

Input:

// formatting looks consistent:
export class ContactCasesComponent1 extends ListWrapperBaseComponent<> {
  method1(options: MethodOptions) {
    return process(options);
  }
}

// formatting looks consistent:
export class ContactCasesComponent2 implements OnInit {
  method1(options: MethodOptions) {
    return process(options);
  }
}

// formatting looks consistent:
export class ContactCasesComponent3 extends ListBase implements OnInit {
  method1(options: MethodOptions) {
    return process(options);
  }
}

// formatting looks consistent:
export class ContactCasesComponent4 extends ListWrapperBaseComponent<
  ContactCasesListItem,
  CasesTableColumns
> {
  method1(options: MethodOptions) {
    return process(options);
  }
}

// Moving the open brace to a separate line does not look consistent to me:
export class ContactCasesComponent5
  extends ListWrapperBaseComponent<ContactCasesListItem, CasesTableColumns>
  implements OnInit {
  method1(options: MethodOptions) {
    return process(options);
  }
}

Output:

// formatting looks consistent:
export class ContactCasesComponent1 extends ListWrapperBaseComponent<> {
  method1(options: MethodOptions) {
    return process(options);
  }
}

// formatting looks consistent:
export class ContactCasesComponent2 implements OnInit {
  method1(options: MethodOptions) {
    return process(options);
  }
}

// formatting looks consistent:
export class ContactCasesComponent3 extends ListBase implements OnInit {
  method1(options: MethodOptions) {
    return process(options);
  }
}

// formatting looks consistent:
export class ContactCasesComponent4 extends ListWrapperBaseComponent<
  ContactCasesListItem,
  CasesTableColumns
> {
  method1(options: MethodOptions) {
    return process(options);
  }
}

// Moving the open brace to a separate line does not look consistent to me:
export class ContactCasesComponent5
  extends ListWrapperBaseComponent<ContactCasesListItem, CasesTableColumns>
  implements OnInit
{
  method1(options: MethodOptions) {
    return process(options);
  }
}

---

P.S. Here is the formatting with playground from PR #9741, right before Prettier 2.2.1:

Prettier pr-9741
Playground link

--parser babel

Input:

// formatting looks consistent:
export class ContactCasesComponent1 extends ListWrapperBaseComponent<> {
  method1(options: MethodOptions) {
    return process(options);
  }
}

// formatting looks consistent:
export class ContactCasesComponent2 implements OnInit {
  method1(options: MethodOptions) {
    return process(options);
  }
}

// formatting looks consistent:
export class ContactCasesComponent3 extends ListBase implements OnInit {
  method1(options: MethodOptions) {
    return process(options);
  }
}

// formatting looks consistent:
export class ContactCasesComponent4 extends ListWrapperBaseComponent<
  ContactCasesListItem,
  CasesTableColumns
> {
  method1(options: MethodOptions) {
    return process(options);
  }
}

// open brace is still on the same line in Prettier 2.2.1:
export class ContactCasesComponent5
  extends ListWrapperBaseComponent<ContactCasesListItem, CasesTableColumns>
  implements OnInit {
  method1(options: MethodOptions) {
    return process(options);
  }
}

Output:

// formatting looks consistent:
export class ContactCasesComponent1 extends ListWrapperBaseComponent<> {
  method1(options: MethodOptions) {
    return process(options);
  }
}

// formatting looks consistent:
export class ContactCasesComponent2 implements OnInit {
  method1(options: MethodOptions) {
    return process(options);
  }
}

// formatting looks consistent:
export class ContactCasesComponent3 extends ListBase implements OnInit {
  method1(options: MethodOptions) {
    return process(options);
  }
}

// formatting looks consistent:
export class ContactCasesComponent4 extends ListWrapperBaseComponent<
  ContactCasesListItem,
  CasesTableColumns
> {
  method1(options: MethodOptions) {
    return process(options);
  }
}

// open brace is still on the same line in Prettier 2.2.1:
export class ContactCasesComponent5
  extends ListWrapperBaseComponent<ContactCasesListItem, CasesTableColumns>
  implements OnInit {
  method1(options: MethodOptions) {
    return process(options);
  }
}

I think this was changed by PR #10085.

---

Please let us know if we should raise a new issue to discuss the formatting of the class declarations.

[ksze]

This output is really ugly:

const LongVar = LongLongLongLongLongFun(param, {
  key1: "value1",
});

I would prefer any of these outputs:

const LongVar = LongLongLongLongLongFun(
  param,
  { key1: "value1" },
);

const LongVar = LongLongLongLongLongFun(param, { key1: "value1" });

const LongVar = LongLongLongLongLongFun(
  param,
  {
    key1: "value1",
  },
);

To illustrate, here's an even worse example.
Input:

foo({a: b},
  a,
  b,
  {
    a: b,
  }, 
)

The current output:

foo({ a: b }, a, b, {
  a: b,
});

This is so inconsistent, it's a complete eyesore.

Note that adding another object at the end of the parameters makes it format differently:
Input:

foo({a: b},
  a,
  b,
  {
    a: b,
  }, {}
)

Output:

foo(
  { a: b },
  a,
  b,
  {
    a: b,
  },
  {},
);

which is much better.

I prefer the function arguments to be either all on a same line as the function name or all indented in the lines below the function name.