First of all, thanks for making this available as a kicking off point for interacting with the App Store server APIs. I was genuinely excited to start using it!
Unfortunately, within seconds of adding this library to my Vapor project, I was immediately met with some new errors: 'Data' is ambiguous for type lookup in this context:
This is unfortunate, as lots of code that uses this will likely be working with Foundation as well, if only for their Codable Request/Response types, leading to the very silly spelling of Foundation.Data (which most would probably wonder why it was even necessary). Could we consider renaming it to AppMetadata or keep it under an AppStore namespace (ie. AppStore.Data)?
Similarly, but less egregious, was a conflict with Vapor's Environment, another package that has an extreme likelihood of being used with this one given its popularity for server-based swift implementations.
This isn't blocking in anyway given I could rename the conflicts with the module name prefix, but it certainly added some friction to the process of getting started, so hoping we could decrease that wherever possible 😊
First of all, thanks for making this available as a kicking off point for interacting with the App Store server APIs. I was genuinely excited to start using it!
Unfortunately, within seconds of adding this library to my Vapor project, I was immediately met with some new errors:
'Data' is ambiguous for type lookup in this context:This is unfortunate, as lots of code that uses this will likely be working with
Foundationas well, if only for theirCodableRequest/Response types, leading to the very silly spelling ofFoundation.Data(which most would probably wonder why it was even necessary). Could we consider renaming it toAppMetadataor keep it under anAppStorenamespace (ie.AppStore.Data)?Similarly, but less egregious, was a conflict with Vapor's
Environment, another package that has an extreme likelihood of being used with this one given its popularity for server-based swift implementations.This isn't blocking in anyway given I could rename the conflicts with the module name prefix, but it certainly added some friction to the process of getting started, so hoping we could decrease that wherever possible 😊