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

Investigate how to distribute CLI outside of SPM #2562

Closed
calvincestari opened this issue Oct 11, 2022 · 2 comments · Fixed by #2659
Closed

Investigate how to distribute CLI outside of SPM #2562

calvincestari opened this issue Oct 11, 2022 · 2 comments · Fixed by #2659
Labels
codegen Issues related to or arising from code generation
Milestone

Comments

@calvincestari
Copy link
Member

calvincestari commented Oct 11, 2022

Using the CLI through SPM plugins is not the best experience and requires the use of options such as --disable-sandbox in order to unlock the full functionality. Is there a way we can distribute the CLI outside of SPM and maintain a strong link to the correct version of apollo-ios.

@calvincestari calvincestari added the codegen Issues related to or arising from code generation label Oct 11, 2022
@calvincestari calvincestari added this to the Next Release (1.0.1) milestone Oct 11, 2022
@AnthonyMDev
Copy link
Contributor

AnthonyMDev commented Oct 21, 2022

I think the only reasonable way to do this is by checking the Package.resolved file.

We should bundle the CLI version in the CodegenCLI.Constants as a hard coded string. (moving it from the apollo-ios-cli, target where it lives currently). Then we compare that against a resolved version for the Apollo dependency.

There are 3 ways to get Apollo:

  • Manual git clone:
    • If you wanna do this, go for it, you can use the make command to build the CLI, but I don’t think there is a good way for us to verify that you aren’t using mismatched versions. If you are going to do everything manually, you need to handle your own build tooling, it shouldn’t be our responsibility.
  • Cocoapods:
    • This is just not a problem, since we re-install the correct version of the CLI when you run pod update
  • SPM:
    • We can look at the Package.resolved file in your project, run it into a JSON serializer, and look for the version of the Apollo ios lib, that should be easy to do once we have that file.
    • We have to find that file, it can be in a few places:
      1. For a project that has a Package.swift file, it will be right next to that.
      • I think the best we can do there is checking the root of the project for the Package.resolved, (ie. the directory containing the apollo-codegen-config.json file).
      1. For a project that includes the SPM Package via Xcode
      • The Package.resolved will be in their .xcodeproj at the path: MyProject.xcodeproj/project.xcworkspace/xcshareddata/swiftpm/Package.resolved
      • I don’t think we should do a recursive deep search of the entire directory, as you could get into a mess of weird issues that we can’t even begin to anticipate with how other people structure their projects. Let’s just look at those 2 specific places.
  • If we don’t find the Package.resolved, then we should just continue on with codegen anyways. This is only a convenience to be checking for them, and if we can’t verify it, we should just assume it’s fine.
    • Worst case, they get confused until the update their codegen CLI, but this is only for edge cases in which their project structure is something we can’t understand.
    • If we get questions from people in the future who are having this problem, we can ask them more about their project structure and perhaps improve the algorithm for finding the Package.resolved, but that’s probably going to be iterative based on customer feedback, not something we can anticipate right now.
  • When we find a mismatched version, we should terminate code generation with a message:
You are running version \(cliVersion) of the Apollo Codegen CLI, but you are using version \(apolloVersion) of the Apollo iOS Library. Please update your version of the Codegen CLI by following the instructions at: https://www.apollographql.com/docs/ios/code-generation/codegen-cli/#installation

To suppress this error and run the CLI anyways, use the argument: --suppress-version-mismatch-error.

CLI Installation

The make build-cli command is not really the easiest. It requires you to have to know where your checkout of apollo-ios is and navigate to it. This could be in some SPM cached packages directory, or it could be right in your project directory but I'm not sure how to tell, and it's not something that we can guarantee is even going to stay the same in the future. Apple could change that.

I think that maybe an SPM plugin command just for actually building and installing the CLI might be a good compromise. It works with both Xcode and Package.swift projects very easily, and doesn't require --disable-sandbox. It would just spit out the apollo-ios-cli executable in your project root directory.

The documentation for installation of the Codegen CLI will need to be updated for this.

The plugin command can just run the make build-cli command (ensuring we build in release mode), then move the built executable into your project root.

@calvincestari
Copy link
Member Author

I think we should rather:

  • distribute the CLI binary with each release on GitHub
  • add the version number to the generated file header

This way it's clear to the user what versions were used and they have access to all the tools (binary + repo) to fix any mismatched version problems. Trying to guess paths, etc. is opportunity for things not to work as expected. I'd rather put the power back into the hands of the user.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
codegen Issues related to or arising from code generation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants