Bug in types.based (or misconception about how it should work)

[dgattey]

I have a protocol called Operation. It's implemented by AdvancedOperation, and there's another class, GroupOperation that's itself a subclass of AdvancedOperation. There are then a ton of AdvancedOperation and GroupOperation subclasses.

With a template that starts with {% for type in types.based.AdvancedOperation %}, none of the GroupOperation subclasses are targeted. If I switch it to types.based.Operation, nothing at all is targeted.

This feels like a bug. Are recursive dependencies supported? As in, shouldn't I get all GroupOperation subclasses when I target AdvancedOperation? If not, why not, and can that feature be added? Alternatively, doing something like {% for type in types.based.AdvancedOperation|GroupOperation %} would work for me too, but that's also not supported.

[krzysztofzablocki]

It should work, might be a regression. If those are known types does types.implementing.AdvancedOperation work?

[dgattey]

Both Advanced and Group operation are in a pod's module (whose source sourcery is indeed looking through). And the subclasses are in another pod's module. With inheriting.AdvancedOperation or implementing.AdvancedOperation, I actually get nothing at all output. Just like targeting Operation

[dgattey]

Might indicate that they're not known types for some reason hmm

[krzysztofzablocki]

Are you pointing sourcery at source code that has definition of protocols or the classes implementing them? Or both?

[ilyapuchka]

Next week I'll work on #87 adding support for scanning multiple targets. This should solve an issue with 3rd party (pods) code

[ilyapuchka]

@dgattey with #193 you should be able to scan CocoaPods dependencies and avoid unknown types 🎉