Improve multiline printing of record types and values #7993
Conversation
rescript
@rescript/darwin-arm64
@rescript/darwin-x64
@rescript/linux-arm64
@rescript/linux-x64
@rescript/runtime
@rescript/win32-x64
commit: |
There was a problem hiding this comment.
Can we first reach consensus with the core contributors before merging?
This sets a precedent, and I think we should have a broader discussion about the direction we want to take.
For context, see my earlier thoughts here: #7961 (comment)
| * }` -> record is written on multiple lines, break the group *) | ||
| let force_break = | ||
| e.pexp_loc.loc_start.pos_lnum < e.pexp_loc.loc_end.pos_lnum | ||
| match (spread_expr, rows) with |
There was a problem hiding this comment.
I want to pause here a bit — I don’t think we should merge this part right now.
The change around force_break introduces behaviour that depends on how the user originally formatted their code. That’s a significant precedent: it ties output formatting decisions to source‑layout heuristics.
If we want to allow this kind of stylistic inference, I believe it needs wider agreement within the core team. We should either decide as a group that this is a direction we’re comfortable with, or explicitly document why we don’t want to go that way.
If we do agree in principle, I’d also like to see a short architectural or design record capturing the rationale and boundaries for this sort of logic, so that future contributions have something concrete to refer to.
Finally, even with buy‑in, I’d suggest postponing this until after v12. We’re in the release‑candidate stage, and introducing new formatting heuristics at this point could have more ripple effects than we realise.
So in short: let’s not merge this specific part yet; let’s first get consensus and document it properly.
2 participants
Fix #7961
The formatting of the transformed JSX forces multiline for props with this change. However, I think this is fine because users won't actually see the transformed JSX anyways.