Appending an optional string / array causes the entire expression to be reformatted

[CyberShadow]

Description

I don't really mind either way, but filing this in case someone might find the following useful.

I think this diff could have been less noisy:
NixOS/nixpkgs@eac5951

Small example input

Consider this initial expression:

{
  exampleString = ''
    hello
    beautiful
  '';
  exampleArray = [
    "hello"
    "beautiful"
  ];
}

Now, we want to add some optional things:

{
  exampleString = ''
    hello
    beautiful
  '' + lib.optionalString true ''
    wonderful
    world
  '';
  exampleArray = [
    "hello"
    "beautiful"
  ] ++ lib.optionals true [
    "wonderful"
    "world"
  ];
}

Expected output

No change - I think the above is close to the existing style.

Actual output

nixfmt-rfc-style reformats the entire thing, creating a big diff:

{
  exampleString =
    ''
      hello
      beautiful
    ''
    + lib.optionalString true ''
      wonderful
      world
    '';
  exampleArray =
    [
      "hello"
      "beautiful"
    ]
    ++ lib.optionals true [
      "wonderful"
      "world"
    ];
}

[MattSturgeon]

Is this an issue with the RFC or with the implementation?

It seems this thread is discussing a similar issue too: https://discourse.nixos.org/t/satisfaction-survey-from-the-new-rfc-166-formatting/49758

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nix-formatting-team-treewide-nixpkgs-formatting/56666/2

[Atemu]

  exampleArray = [
    "hello"
    "beautiful"
  ] ++ lib.optionals true [
    "wonderful"
    "world"
  ];

This is not legal under RFC166 because the closing bracket before ++ is not indented but not on the last line. The compact style shown here may only be used if it only causes the last line to not be indented, all other lines must be indented:

Operator chains in bindings may be compacted as long as all lines between the first and last one are indented.

https://github.com/NixOS/rfcs/blob/master/rfcs/0166-nix-formatting.md#chainable-operators

If you're used to the RFC style, this property is extremely important to parsing operator chains (aswell as bindings in general) quickly mentally and encountering a non-indented line that is not the last line of the binding is confusing.

I don't see a good way to solve this but, as mentioned in https://discourse.nixos.org/t/nix-formatting-team-treewide-nixpkgs-formatting/56666/3, you could pre-emptively force the non-compact form using a comment or a no-op expression if you anticipate that an operator will be used on your expression in the future.