typealiased
Fix JSON package dump compatibility…
…since JSON package descriptions do not always seem to include target dependencies.
I'm not thrilled with this since the package dump doesn't include sources, but the path to them. Not thrilled with how complex the decoding logic is becoming.
Filed SR-14972.
@andrewchang-bird I'm looking at the SwiftPM library and wondering if Mockingbird should use it instead of recreating all this JSON parsing, assumptions about implicit paths etc?
Going off this example, it looks like it should be possible to ask libSwiftPM to load a package and return the targets, their dependencies and target source files. It seems to offer the appropriate level of abstraction over targets, dependencies and sources.
However, at this point it this seems like the changes are evolving the JSON project feature beyond its original use case since it is basically allowing developers to pass a package as the project: mockingbird generate --project path/to/Package.swift --target Feature.
In absence of such a feature, my team and I would have to create and maintain Xcode workspaces and projects for our packages just to generate mocks. This is obviously undesirable. It seems to me this pattern of small, focused modules is gaining traction in the community, too. What do you think?
I think it’s definitely worth looking into. I’m prioritizing some big changes to the framework and generator for 0.18, so if you have the bandwidth it would help tremendously. Note that you’ll have to bump the existing version of SPM that’s being linked in for argument parsing. Not sure about the compatibility, but the CLI should probably use the newer Swift Argument Parser lib instead regardless.
