Proposal: change formatting for arrays and objects

[xDivisionByZerox]

Clear and concise description of the problem

Arrays currently get autoformatted by prettier, based on the length they take up on the line. This can lead to a one-liner with multiple values in it:

const arr = ['a', 'b', 'c', 'd', 'e', 'g'];

If I now change one value in this array the git diff only has one line to work with, what can spotting differences very hard (IMO):

- const arr = ['a', 'b', 'c', 'd', 'e', 'g'];
+ const arr = ['a', 'b', 'c', 'd', 'e', 'f'];

Opposite to that would be to put each entry in its own line. That way changes can be spotted much easier:

const arr = [
  'a', 
  'b', 
  'c', 
  'd', 
  'e', 
-  'g',
+  'f',
];

Suggested solution

Use eslint's array-element-newline rule with the configuration set to always.

Alternative

No response

Additional context

I don't know how eslint and prettier behave together regarding this setting (since prettier would want to always format the array to a one-liner).

[ST-DDT]

I see the use for longer arrays or arrays that tend to change. However, for short arrays or arrays that never really change that might make it longer.

I'm fine with both variants.

[xDivisionByZerox]

There is also an option to only apply the rule if the array has a minimal length.

[import-brain]

Yes, I think it would be best if we applied the rule on all arrays above a certain length.

[Shinigami92]

IMO this is not really a good idea

eslint and prettier will get in conflict with that and setting it to a certain limit length is also not helpful depending on the length of the content :shrug: So if the content is to long anyways the array will wrap on a printWidth of 80 cols And if the content is small enough than it is a case where it is not hard to see the diff (at least with a little bit of headache)

These cases are very rare anyway, and when they're in the code, they really rarely change