-
Notifications
You must be signed in to change notification settings - Fork 730
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
update: CLI defaults #2673
update: CLI defaults #2673
Conversation
✅ Deploy Preview for apollo-ios-docs ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
Tests/ApolloCodegenTests/CodeGeneration/Templates/InputObjectTemplateTests.swift
Show resolved
Hide resolved
Tests/ApolloCodegenTests/CodeGeneration/Templates/InputObjectTemplateTests.swift
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.
Looks really good, just a couple comments around tests and documentation mostly!
I want to do a more comprehensive review of the docs because this only shows the files you did change, and I think there should be some additions to docs in the getting started guide (and maybe other areas?) to really explain that you need to pick a module type and link to the section of the docs that explains what each of those options really does.
I think the docs need to clearly explain that this is a decision that affects your project structure, and depending on what you select here, how you include your generated files is going to be significantly different.
``` | ||
|
||
`${MySchemaName}` should be the name you want for the namespace of your generated schema files. | ||
* `${MySchemaName}` should be the name you want for the namespace of your generated schema files. | ||
* `other` is the module type to use when your dependency manager for Apollo iOS is CocoaPods. |
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.
I think I have a problem with this. Let's talk about it more.
I don't think that telling them it's a no-brainer and just to use other
if they are using Cocoapods is accurate.
other
is used if you want to package your generated schema as a separate module and distribute that as a Pod. But what we've found is that most users actually just want to embed the generated models right into their application target. They are just including Apollo
via Cocoapods.
Even though we don't believe that is the best choice, it does seem to be the default expectation of users. So I think embeddedInTarget
is still the default module type people would want to use. Either way, we should be very clear in explaining to people that this is a choice to be made and they should understand what the implications of each possible choice is. That way we aren't making embeddedInTarget
the path of least resistance, but we also aren't confusing people who assumed that it would work that way, when their generated files don't link to their project and build properly.
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.
This is in a CocoaPods focused panel, which is why it says to use other
- it's contextual.
If they added Apollo to their project via CocoaPods the CLI is built with the COCOAPODS
flag and will therefore always add cocoapodsCompatibleImportStatements=true
to the initialization file. This happens without them knowing and if they used anything other than other
the generated code wouldn't build because the import
statements would be incorrect.
There is nuance and edge cases but the overwhelming majority of users that use CocoaPods should be using other
as the module type here.
``` | ||
|
||
`${MySchemaName}` should be the name you want for the namespace of your generated schema files. | ||
* `${MySchemaName}` should be the name you want for the namespace of your generated schema files. | ||
* `swiftPackageManager` is the module type to use when your dependency manager for Apollo iOS is Swift Package Manager. |
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.
Same as above
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.
This is in an SPM focused panel, also contextual.
@@ -71,11 +94,69 @@ class InitializeTests: XCTestCase { | |||
expect(command.schemaName).to(equal("ShortFormatSchemaName")) | |||
} | |||
|
|||
func test__parsing__givenParameters_moduleNameLongFormat_shouldParse() throws { |
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.
While these tests are awesome and super comprehensive, remind me to have a conversation with you about my views on testing behavior vs configuration! Would love to save you some time in the future possibly.
\(supportCocoaPods ? "\"other\"" : "\"swiftPackageManager\"") : { | ||
} | ||
"\(moduleType)" : { | ||
\(moduleTarget) |
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.
I could be wrong, but this looks like the indentation is off, and that it may be missing a }
? Not sure. Do we have unit tests for this? (I have another comment in the InitializeTests
asking about testing this as well.)
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.
The JSON is correct, otherwise none of the decoding from the return string of minimalJSON
into an ApolloCodegenConfiguration
instance would succeed.
The indentation is also correct, it looks odd because of where \(moduleTarget)
is on line 221. If that was indented two more to 'look' correct, then 194 would need to move two backwards.
Yes, I agree with this. More thorough explanation of the modules types will save us a bunch of issues being created and help users to be less confused about the output they get. |
Closes #2595
swift-argument-parser
dependency to the latest version,1.2.0
(both SPM and Xcode)output.operations
default to.inSchemaModule
--module-type
on CLIinit
command--target-name
when the module type is.embeddedInTarget
init
command to detail the new parameters