Thanks for the PR, @pfgithub!

typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community.

The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately.

Thanks again!

🙏 Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently on https://opencollective.com/typescript-eslint. As a thank you, your profile/company logo will be added to our main README which receives thousands of unique visitors per day.

Codecov Report

Merging #2970 (17c71a8) into master (1932c8b) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master    #2970   +/-   ##
=======================================
  Coverage   92.74%   92.74%           
=======================================
  Files         313      313           
  Lines       10636    10644    +8     
  Branches     3017     3021    +4     
=======================================
+ Hits         9864     9872    +8     
  Misses        353      353           
  Partials      419      419           

Flags with carried forward coverage won't be shown. Click here to find out more.

Could you explain more about this and why you want this change?
We generally prefer you raise an issue before just making this kind of breaking change, so that it can be discussed.

I'm not sure I agree that

type T = {a: string, b: {

}};

Should be considered a "single line" type - because it's not really a single line type.

The purpose of singleLine member delimiter style is to make single line types not need a trailing delimiter or have a different delimiter

const T = {a: {}}; instead of {a: {};};

When a type spans multiple lines but only its members have newlines, it looks weird for it to use the multiline delimiter style (especially with commas)

const T = {a: {b: {
    c: true,
},},}; // current
const T = {a: {b: {
    c: true,
}}}; // changed

This change won't affect anyone using prettier because prettier doesn't allow code to be formatted like that (link) (although people using prettier probably aren't using member-delimiter-style)

To clarify - I understand the change itself, completely.

I'm trying to understand the use case better. The why.
Why are you formatting your types like this with types defined using different conventions?

This rule has existed for >2 years without this functionality.
Because this is a breaking change (anyone who was using the rule without prettier will now have to change their code), I need a good reason for us to break it.

This change won't affect anyone using prettier because prettier doesn't allow code to be formatted like that

Correct, because prettier enforces a consistent code style in this context.

The eslint comma-dangle property, when set to "always-multiline", doesn't enforce if the last member is on the same line as the }. I have updated this PR to have an option for deciding how to treat this so it doesn't break any existing code.