Swiftlint: file_types_order: false positive with PreviewProvider subclasses in SwiftUI

[weakfl]

New Issue Checklist

• [x] Updated SwiftLint to the latest version
• [x] I searched for existing GitHub issues

Describe the bug

file_types_order triggers when multiple classes are declared in the same file:

class Foo {
}

class Bar: Foo {
}

Environment

• SwiftLint version: 0.35.0
• Installation method used: Homebrew

[timbms]

Fixing this rule will become even more of an issue with SwiftUI with structs derived from View and PreviewProvider in the same file

struct ContentView: View {
    var body: some View {
        Text("Hello World")
    }
}

struct ContentView_Previews: PreviewProvider {
    static var previews: some View {
        ContentView()
    }
}

[Jeehut]

@timbms I agree that it doesn't make sense to put the PreviewProvider above the actual view. Since this is a very SwiftUI-specific thing, I think we should handle PreviewProvider subclasses as a special file type and place it even below extensions by default. Will make a PR for that soonish.

[Jeehut]

@weakfl That's actually the expected behavior. When there are multiple classes within a file, the class whose names matches the file name is considered to be the main type and thus other types (including classes) are declared supportingTypes. In case that there is no type matching the file name, the class with the most lines of code is considered to be the main type.

The best way to make sure the rule works correctly is to use it together with the File Name rule and to separate main types always into their own files, only keeping supporting types in a single file with the main type.

[weakfl]

@Jeehut Thanks for the explanation. It feels a bit counter intuitive to declare derived classes before the main class, but maybe that's just me?

Would be great if this could be configured. Same goes for order of properties (see #2410).

[Jeehut]

@weakfl And I find it counter-intuitive to find two main types in a single Swift file. A subclass should always be in its own file in my opinion. At least in projects where it would make sense to enable this rule.