Tips for migrating from NPM-based codegen to apollo-ios-cli?

Help
, , ,
1

Hi there! I’m trying to upgrade our iOS project from the old NPM-based code gen to the new apollo-ios-cli. To start, I’m hoping to configure the apollo-ios-cli to work similarly to our current setup. I’ve been reading the new config documentation, but I feel like I’m spinning my wheels a bit.

A bit of background. We have a single GQL/SharedFragments directory, and then a ton of Modules/Sources/<ModuleName>. We run code gen over each module by:

  1. cding into each module directory
  2. copying relevant content from GQL/SharedFragments into it
  3. Running apollo codegen:generate as below.
  4. Deleting the copied fragments
  5. Saving each module’s single API.generated.swift output

Any advice on how to configure the CLI? I’ve been passing --string with module-specific parameters to start. Should I use moduleType as embeddedInTarget or other? Is there still a way to generate a single Swift file? Or, should I store shared types in some central place, now?

Here’s the specific command we use to run the code-gen in each module, for reference.

apollo codegen:generate \
    --target=swift \
    --includes=*.graphql \
    --excludes=schema.graphql \
    --localSchemaFile=schema.graphql \
    --passthroughCustomScalars \
    --namespace=API \
    ../API.generated.swift

Thank you!

2

Hey there @jamesonwilliams! Sorry it took us a few days to respond to you!

Instead of reading the configuration reference docs, this guide on project configuration might help make it make more sense to you.

We no longer provide a way to generate a single Swift file for the API. You’ll have separate files for each operation, fragment, and schema type.

With Apollo iOS 1.0, we highly recommend that you run codegen just once over the entire project, rather than individually over specific modules. If you feel really strongly that you need to run codegen over modules separately, I can give you some pointers there, but it’s not the best idea.

Apollo iOS 1.0 requires the schema types to be generated and referenced by all the generated operation models. This means you’ll be generating separate schema info for each module you run codegen for. In addition, you’re generating the same “Shared Fragments” in each of your API files now, but you can share them across modules! That could end up being unnecessary code compiled into your app we can get rid of.

What I would recommend is this:

  • For schemaTypes:
    • Use the .moduleType of .swiftPackageManager
      • This creates the shared schema module with a Package.swift file so you can import it via SPM. If you use Cocoapods or manual Xcode targets, use the .other value and then create your own package from the generated files in your schema module.
    • Set the path to a location that you want all of your shared GraphQL code to live.
      • The schema types that all the other operation models use will live here, but you will also put the generated models for shared fragments there.
  • For operations:
    • Use the .relative value.
      • That will make it so that the operation models are generated relative to the corresponding .graphql files.
  • Move your shared fragment .graphql files somewhere inside the directory that you used as the path for your schemaTypes.
  • You can then move your .graphql operation files around to determine where all of the generated models will be located. Use the subpath parameter if you want them generated in a sub-folder relative to the corresponding .graphql files.

When you run codegen this way, the operation models will be located inside of their modules, but the schema types and shared fragments will be in the shared schema module. All of the generated operation models will have generated import statements to import that module, so just link all your other modules to the schema module and you should be good to go!

Let me know if this works for you or if you have any other issues!