You can reduce the churn slightly and conform more closely to the house style by doing this instead:

  object-curly-spacing: [error, always, {objectsInObjects: false}]

That flags 2144 problems in the current code base, instead of the 2183 flagged with the PR as it is. That's not a huge reduction, but every little bit helps to make backporting less awful.

99% of these changes were made using eslint --fix automatically. Except for ~30 cases where the insertion of spaces then caused the line to grow longer than 80 characters, which I cleaned up manually following my own stylistic judgement and ensuring eslint passes.

In general it's useful to do the automatic ones as one commit, and then the manual ones as a separate one. They'll get squashed on landing, but it means people can review the ones that weren't just an eslint --fix (which are probably the more interesting ones).

This change is unrelated and should be done in another PR.

This was done in response to: #14162 (comment)

I understand it's not 100% the same property but opening another PR seems a little bureaucratic. It's a purely aesthetic change in line with the comment.

@sebdeckers "bureaucratic" rules have their reasons ;) One of them is that keeping commits logically separated makes backporting a lot easier. Most of the changes from this PR are probably going to have numerous conflicts with release branches, while this one would have been cherry-picked cleanly.

I agree with @aqrln in the general case, but in this case since it's most probably gonna be backported by cherry picking just the rules change, then running eslint --fix, hopefully this wouldn't cause a mess 🙏