-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feature: Adding codegen config support for spm module type versions #539
Conversation
Setup codegen config options and tests for new spm module type version
✅ Docs Preview ReadyConfiguration{
"repoOverrides": {
"apollographql/apollo-ios-dev@main": {
"remote": {
"owner": "apollographql",
"repo": "apollo-ios-dev",
"branch": "feature/package-config-3017"
}
}
}
}
15 pages published. Build will be available for 30 days. |
✅ Deploy Preview for apollo-ios-docc canceled.
|
✅ Deploy Preview for eclectic-pie-88a2ba ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor comment on the case naming but otherwise I think this looks good so far. Still the swift package manager module template changes to implement right?
...o-ios-codegen/Sources/ApolloCodegenLib/CodegenConfiguration/ApolloCodegenConfiguration.swift
Outdated
Show resolved
Hide resolved
Finished implementation in SchemaModuleTemplate for new spm module type versions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for doing this Zach! A couple things I'd like us to consider here before merging this.
...o-ios-codegen/Sources/ApolloCodegenLib/CodegenConfiguration/ApolloCodegenConfiguration.swift
Outdated
Show resolved
Hide resolved
apollo-ios-codegen/Sources/ApolloCodegenLib/Templates/SwiftPackageManagerModuleTemplate.swift
Outdated
Show resolved
Hide resolved
...o-ios-codegen/Sources/ApolloCodegenLib/CodegenConfiguration/ApolloCodegenConfiguration.swift
Outdated
Show resolved
Hide resolved
...o-ios-codegen/Sources/ApolloCodegenLib/CodegenConfiguration/ApolloCodegenConfiguration.swift
Outdated
Show resolved
Hide resolved
...o-ios-codegen/Sources/ApolloCodegenLib/CodegenConfiguration/ApolloCodegenConfiguration.swift
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewing this again got me thinking. Is it worth adding an option for users to point their Apollo dependency to their own fork? Right now you can point to a branch or commit hash, but it's still only on the url https://github.com/apollographql/apollo-ios.git
.
@BobaFetters @calvincestari do you think that's worth doing at this time?
...o-ios-codegen/Sources/ApolloCodegenLib/CodegenConfiguration/ApolloCodegenConfiguration.swift
Outdated
Show resolved
Hide resolved
...o-ios-codegen/Sources/ApolloCodegenLib/CodegenConfiguration/ApolloCodegenConfiguration.swift
Outdated
Show resolved
Hide resolved
I don't see any reason why we'd want to restrict it to |
I just had the thought that maybe allowing something other than |
Likely you're just making some changes in your fork that don't affect codegen compatibility, but yeah any manual dependency here means you may generate incompatible code. That's something the user needs to accept and deal with on their own. If you're using anything but the default package version, we shouldn't even be using the version checker at all actually. The version checker isn't foolproof right now anyways. It only runs on the CLI, not Swift Scripts, and if it can't find a package.resolved file, it won't run at all. But worse case, you generate code that doesn't compile properly and you know it when you try to build. This is just to attempt to detect that early and give you a clear error message. But I'm actually wondering if we should move this into |
Yes we probably should, and in a separate PR. |
I don't see a reason not to add that, I guess maybe add a url associated value that defaults to |
...o-ios-codegen/Sources/ApolloCodegenLib/CodegenConfiguration/ApolloCodegenConfiguration.swift
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Love this API now. I think the changes we made are great and this is the right way forward now. Great work @BobaFetters!
I've got a couple minor suggestions, and we're still waiting on documentation. But the core of this is looking good!
Tests/ApolloCodegenTests/ApolloCodegenConfigurationCodableTests.swift
Outdated
Show resolved
Hide resolved
...o-ios-codegen/Sources/ApolloCodegenLib/CodegenConfiguration/ApolloCodegenConfiguration.swift
Outdated
Show resolved
Hide resolved
@@ -106,7 +106,7 @@ The properties to configure `output` are: | |||
"output": { | |||
"schemaTypes": { | |||
"moduleType": { | |||
"swiftPackageManager": {} | |||
"swiftPackage": {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's long bugged me that we had swiftPackageManager
as a ModuleType
option and swiftPackage
as a TestMocks
option; I'm happy these are more similar now. 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, nice work!
@@ -283,7 +283,12 @@ public struct ApolloCodegenConfiguration: Codable, Equatable { | |||
case embeddedInTarget(name: String, accessModifier: AccessModifier = .internal) | |||
/// Generates a `Package.swift` file that is suitable for linking the generated schema types | |||
/// files to your project using Swift Package Manager. | |||
/// Attention: This case has been deprecated, use .swiftPackage(apolloSDKVersion:) case instead. | |||
case swiftPackageManager |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do we eventually remove these cases if we can't signal ahead of time with the deprecation attribute? Removing them in a future major version seems impossible if we're relying on people reading the documentation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Think it just has to be removed in a major version and noted in release notes. Not much else to do without adding the actual deprecation warning.
…for spm module type versions git-subtree-dir: apollo-ios git-subtree-mainline: c528c4d git-subtree-split: 38eef8f5109fd9677ce9a709f2632b8783536ac3
cfe27487 feature: Adding codegen config support for spm module type versions (#539) git-subtree-dir: apollo-ios-codegen git-subtree-split: cfe274876fa5e45b4bebef97beae278331681fd1
…support for spm module type versions git-subtree-dir: apollo-ios-codegen git-subtree-mainline: dbf486f git-subtree-split: cfe274876fa5e45b4bebef97beae278331681fd1
Adding new codegen config options for supplying a version to the SPM module type to allow for pointing to specific branches or local versions.
Closes apollographql/apollo-ios#3017