Consider partnering with IBAnalyzer

[Sherlouk]

I've recently come to see your tool as well as IBAnalyzer and I feel there could be quite a powerful library coming out of the these two tools being combined?

Regardless of a partnership or matching functionality, I feel the features would definitely compliment one another and provide a one-stop spot for normalising and detecting issues with interface files!

Just throwing the idea out there, loving the work you've done so far!

[kateinoigakukun]

Thanks for your suggestion. I have checked IBAnalyzer and I feel it's futures are so powerful.
I'm working in progress in this branch for implementation of IB connection validation. 👍

[piobyz]

I totally agree with @Sherlouk regarding partnership.
Especially because @fastred replied fastred/IBAnalyzer#32
Is this something @kateinoigakukun you would be interested in?

Another idea: why not integrating all IB-related rules into SwiftLint itself?
@kateinoigakukun Have you considered that option? Is there any interest in SwiftLint community?

[SD10]

I would be interested in this 😃

[kateinoigakukun]

@piobyz Thanks for contact with @fastred.

Looks nice! Feel free to use any ideas from IBAnalyzer. :)

I worry about performance for using SourceKitten which is also used in SwiftLint. So considering performance, integrating into SwiftLint is interested! But that changes will may be broke both IBLinter and SwiftLint architecture. And IBLinterCore doesn't parse completely xml, so can't extract all IB connection.

For these reasons, we need to argue how to implement this feature 😓 Do you have any idea? (cc: @SD10 )

[SD10]

@kateinoigakukun

And IBLinterCore doesn't parse completely xml, so can't extract all IB connection.

It shouldn't be too difficult to parse the IB connections in IBLinterCore? We just need to model them and then implement the decoding methods.

I worry about performance for using SourceKitten which is also used in SwiftLint.

I haven't dug into SourceKitten yet, so I'm unaware of the performance implications, but we should try and keep these components as separate as possible.

In my opinion, it would be really great if we could extract IBLinterCore into a separate project - possible IBDecodable. Then make this project's sole concern to turn XML into Swift models. It should be agnostic of SourceKitten and IBLinter.

Maybe we can do something similar with the SourceKitten side of IBAnalyzer.

[kateinoigakukun]

@SD10

We just need to model them and then implement the decoding methods.

I can't figure out how to model all IB connection keeping connection owner's id with IBLinterCore decoding protocol 😢. (I tried but not good implementation https://github.com/kateinoigakukun/IBLinter/pull/9)
Could you implement the decoding methods or tell me how it works?

we should try and keep these components as separate as possible.

In my opinion, it would be really great if we could extract IBLinterCore into a separate project - possible IBDecodable.

I agree. When your this PR https://github.com/kateinoigakukun/IBLinter/pull/30 is finished, we can separate project! 🙌

[SD10]

@kateinoigakukun I will look at decoding outlets. I think that something we need to do is every time we see an id while parsing, we store it in a dictionary that maps to the view.

_{Sent with GitHawk}

[SD10]

I worry about performance for using SourceKitten which is also used in SwiftLint.

@kateinoigakukun I understand what you mean by this now. This bothers me too. I wonder if some change can be made to SwiftLint to allow it to share the results of SourceKitten parsing with IBLinter?

[kateinoigakukun]

@SD10 Thank you for digging.
Even now SwiftLint saves parse results as cache. But using this cache is not recommended.
I wonder if there were the layer to parseSwift AST and save the result in shared file which were used by SwiftLint and IBLinter.

[SD10]

I wonder if there were the layer to parseSwift AST and save the result in shared file which were used by SwiftLint and IBLinter.

Yeah, I was thinking of this. Maybe SwiftLint could provide the AST in a temp file. Then we could check if there is data inside this file, if not, parse ourselves. It would require opening an issue at SwiftLint and asking them what they can do.