search

apollographql / apollo-ios

📱  A strongly-typed, caching GraphQL client for iOS, written in Swift.
https://www.apollographql.com/docs/ios/
MIT License
3.87k stars 714 forks source link

Codegen for `moduleType` `swiftPackageManager` uses hardcoded dependency version #3313

Closed postmechanical closed 8 months ago

postmechanical commented 8 months ago

Summary

When using apollo-ios-cli with a configuration that specifies moduleType swiftPackageManager the resulting generated Package.swift uses a hardcoded dependency version of 1.0.0 rather than that of the version of the toolset in use.

Version

1.7.1

Steps to reproduce the behavior

Run apollo-ios-cli version 1.7.1 to generate code with moduleType swiftPackageManager.

Logs

No response

Anything else?

No response

calvincestari commented 8 months ago

Hi @postmechanical - is this causing an issue for you?

This is intentional as it's only specifying the minimum version requirement of the dependency. We could be updating it to a minimum of each minor release but I don't think that's necessary as SPM should still resolve to the latest 1.x version available.

postmechanical commented 8 months ago

@calvincestari Yes, it is causing a problem. We prefer to pin to exact versions in our dependencies. Anytime anyone runs codegen the target Package.swift has changes that must be reverted. It's not just the hardcoded dependency version that's a problem either but also the other elements of the hardcoded Package.swift template step on the target Package.swift file. The hardcoded template body approach is wholly problematic. We've worked around the issue by using moduleType other now but either the docs or the approach need to be updated to make it clear to users the limitations of the current swiftPackageManager option.

calvincestari commented 8 months ago

We have issue https://github.com/apollographql/apollo-ios/issues/2839 that is intended to allow for manual edits to the SPM manifest without overwriting it on the next codegen. Will that resolve the issue for you and your team?

I agree there are limits to the templating model without the configuration becoming a burden of complexity. The 'other' module type is intended to give more freedom of configuration.

postmechanical commented 8 months ago

@calvincestari Sounds good. Would be great to see associated documentation updates as well to spare others the trouble in the future.