Skip to content
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

Merged
merged 10 commits into from
Nov 17, 2022
Merged

update: CLI defaults #2673

merged 10 commits into from
Nov 17, 2022

Conversation

calvincestari
Copy link
Member

Closes #2595

  • Updates the swift-argument-parser dependency to the latest version, 1.2.0 (both SPM and Xcode)
  • Changes output.operations default to .inSchemaModule
  • Requires the user to specify --module-type on CLI init command
  • Requires the user to specify --target-name when the module type is .embeddedInTarget
  • Updates all documentation referencing the init command to detail the new parameters

@netlify
Copy link

netlify bot commented Nov 16, 2022

Deploy Preview for apollo-ios-docs ready!

Name Link
🔨 Latest commit 7a73efd
🔍 Latest deploy log https://app.netlify.com/sites/apollo-ios-docs/deploys/63769459ed87680008348f8a
😎 Deploy Preview https://deploy-preview-2673--apollo-ios-docs.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site settings.

Copy link
Contributor

@AnthonyMDev AnthonyMDev left a 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.
Copy link
Contributor

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.

Copy link
Member Author

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above

Copy link
Member Author

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 {
Copy link
Contributor

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)
Copy link
Contributor

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.)

Copy link
Member Author

@calvincestari calvincestari Nov 17, 2022

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.

@calvincestari
Copy link
Member Author

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.

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.

@calvincestari calvincestari merged commit 5b2336c into main Nov 17, 2022
@calvincestari calvincestari deleted the update/codegen-cli-defaults branch November 17, 2022 21:38
@calvincestari calvincestari mentioned this pull request Nov 18, 2022
7 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

CodegenCLI - Improve first experience defaults
2 participants