Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

file_types_order: false positive with PreviewProvider subclasses in SwiftUI #2860

Closed
2 tasks done
weakfl opened this issue Sep 4, 2019 · 5 comments · Fixed by #3063
Closed
2 tasks done

file_types_order: false positive with PreviewProvider subclasses in SwiftUI #2860

weakfl opened this issue Sep 4, 2019 · 5 comments · Fixed by #3063

Comments

@weakfl
Copy link

weakfl commented Sep 4, 2019

New Issue Checklist

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
Copy link

timbms commented Oct 2, 2019

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
Copy link
Collaborator

Jeehut commented Feb 1, 2020

@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 Jeehut changed the title file_types_order: false positive with multiple classes in the same file file_types_order: false positive with PreviewProvider subclasses in SwiftUI Feb 1, 2020
@Jeehut
Copy link
Collaborator

Jeehut commented Feb 1, 2020

@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
Copy link
Author

weakfl commented Feb 3, 2020

@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
Copy link
Collaborator

Jeehut commented Feb 3, 2020

@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.

PaulTaykalo added a commit that referenced this issue Apr 24, 2020
Fixes #2860.

Co-authored-by: Paul Taykalo <tt.kilew@gmail.com>
pull bot pushed a commit to scope-demo/SwiftLint that referenced this issue Apr 24, 2020
Fixes realm#2860.

Co-authored-by: Paul Taykalo <tt.kilew@gmail.com>
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants