Identify System Framework Dependencies

[Sherlouk]

The very specific use case that I'm looking for here is the ability to find packages easily which support SwiftUI, naively by the fact that they import SwiftUI. (or as the tables slowly turn, packages which support UIKit or AppKit or maybe I want to find packages relating to ARKit or AVFoundation).

This is very likely some form of static analysis which would be part of the build system to identify imports within the codebase, find all unique references, and report that back.

Thoughts?

[daveverwer]

I do have thoughts!

I first talked about this with someone back in the SwiftPM Library days! Their use case was actually for filtering on imported frameworks as they have a rule that any dependency that imported a UI framework (UIKit at the time) is more trouble than it's worth. It's not a bad rule, either!

However, before we talk about filtering, we need to find and store the data and figure out how/where to display it!

You're almost certainly correct that the answer to collecting this data would become part of the build system, but before diving into that, we'd want to work towards a proof of concept that gets the data out in any format. We can then decide the usefulness of what we can extract and start planning the feature.

If you'd like to start investigating that proof of concept, that'd be some valuable work! 🚀

[Sherlouk]

I'm not sure what the tech stack is over on the analysis/build side, but I wonder if we could use swift-syntax to visit all import statements in every file (ImportDecl) then group that perhaps with a count?

[
  { name: "UIKit", count: 5 },
  { name: "SwiftUI", count: 2 },
]

The count being useful to naively rank them - if there's more UIKit than SwiftUI then it's likely a UIKit library wrapped with a SwiftUI view representable. Probably wouldn't surface the numbers to the user, but would help with the visualisation within the package perhaps. "Relies most on SwiftUI" (if that's top ranked).

Might be completely off the mark here though, this is clearly not going to be a perfect solution but without getting into deep analysis where we look at every type and attribute it back to a framework, I'm not sure on the best option. Let me know what you think though if you genuinely have an idea on how you would approach this.

Definitely agree that step one is get the data and show it before worrying about filters though.

[daveverwer]

Interesting. My gut feeling was that information would come from a binary rather than source code.

but would help with the visualisation within the package perhaps. "Relies most on SwiftUI" (if that's top-ranked).

I wouldn't be against storing the numbers if we end up with them, but I would be against inferring from that data in this way. I think this should be a simple list of frameworks that it's linked against. If that's possible.

Might be completely off the mark here though, this is clearly not going to be a perfect solution but without getting into deep analysis where we look at every type and attribute it back to a framework, I'm not sure on the best option. Let me know what you think though if you genuinely have an idea on how you would approach this.

Yes, I agree this would be overkill. I think the question we're trying to answer here is "What frameworks does this package link against?" which is why I thought it'd maybe come from the binary.

[Sherlouk]

Hadn't considered analysing the output binary itself, let me take a look into that idea some more and get back to you.