Problem with schemaName

[pchmelar]

Bug report

• Thanks for the 1.0.0 release! ❤️ I just integrated it into our testing project, and I have one particular problem with schemaName

Steps to reproduce

• I'm using ModuleType.embeddedInTarget and TestMockFileOutput.absolute options.
• When schemaName is in lowercase ("schemaName": "rocket" for example), the rocket.graphql.swift with the Rocket caseless namespace enum is created. However, the generated Mocks are not working, because there is rocket instead of Rocket.
• When I change the schemaName to start with the capitalized letter ("schemaName": "Rocket" for example), the file with caseless namespace enum isn't created at all. 😔

Versions

• apollo-ios SDK version: 1.0.0
• Xcode version: 14.0
• Swift version: 5.7
• Package manager: SPM

[AnthonyMDev]

Thanks for alerting us to this one. Supports a lowercase named schema here should be an easy fix, we'll get a PR up for that ASAP and release it as part of the first patch version. (We're at GraphQL summit this week, so that will probably be on Monday when we're back!)

When I change the schemaName to start with the capitalized letter ("schemaName": "Rocket" for example), the file with caseless namespace enum isn't created at all. 😔

This definitely shouldn't be happening. I'm not sure why it would not create the enum. I'll see if we can reproduce that...

[SilverTab]

Can reproduce the issue on my end; Using a lowercase schema name results in code that doesn't compile, and using a capitalized schema name, one file is missing from the code generation and the project also doesn't compile. Only way I can get it to compile is to use a lower case name (i.e. rocket), and manually change the generated code to Rocket to get it to build.

[calvincestari]

@SilverTab are you able to share with me a project (schema + operations + config) that demonstrates the second issue - missing file? I can replicate the first issue of test mocks using the incorrectly cased type but not the second missing file bug. If you are you can send it to me at [email protected] - thanks.

[AnthonyMDev]

@calvincestari so this wasn't due to having a type named Rocket then?

[SilverTab]

@calvincestari I'll try to put something together! In the meantime, if that helps; it seems like I didn't have any issues (with lowercase or uppercase schema name) before I started using Fragments in my project 🤔 That's when the error showed up.

[calvincestari]

Hmm, the fragment thing is interesting but I can't say I've noticed those specifically causing a problem.

@AnthonyMDev and I were talking this morning about the missing file and we wondered if it could be a bug in the pruning code; the fact that you're getting some but not all of the generated files is very odd. Can you add the options config to your configuration file and disable pruning, then run codegen again and see whether the file is still missing.

[calvincestari]

For transparency of where we are on this issue:

• I can replicate the lowercase mock object issue and it's down to inconsistency of where we uppercase the schema name type, we'll get that fixed.
• There is a bug where using a schema name the same name as a type will cause build errors, we'll get that fixed.
• I cannot replicate a missing file though, this is the one that I'm still searching for. Bug in pruneGeneratedFiles is causing the namespacing enum file to be erroneously deleted.

[pchmelar]

@calvincestari Yup, I can confirm that. Once I've added "pruneGeneratedFiles": false to my configuration, the Rocket.graphql.swift is successfully generated. Hope that helps with fixing the issue. 🙂

[calvincestari]

@calvincestari Yup, I can confirm that. Once I've added "pruneGeneratedFiles": false to my configuration, the Rocket.graphql.swift is successfully generated. Hope that helps with fixing the issue. 🙂

Awesome, that's a solid lead on getting it resolved. Thanks for trying it!

[SilverTab]

Same here! "pruneGeneratedFiles": false fixes it! :)

[indama]

Hi guys,

Using pod version of Apollo here.

I have another issue:

Config:

Errors:

[AnthonyMDev]

You need to add cocoapodsCompatibleImportStatements: true to your config options.
See the config docs here: https://www.apollographql.com/docs/ios/code-generation/codegen-configuration/#output-options

When you init the codegen config using the CLi built by Cocoapods, it adds this option automatically, so I'm kinda interested to hear how you set this up to not have the option already there!

FWIW, the SchemaConfiguration file and any of your CustomScalars won't get overwritten, so you'll need to just change those manually to import Apollo instead of import ApolloAPI. (We're going to work on fixing that issue as well soon.)

[indama]

You need to add cocoapodsCompatibleImportStatements: true to your config options. See the config docs here: https://www.apollographql.com/docs/ios/code-generation/codegen-configuration/#output-options

When you init the codegen config using the CLi built by Cocoapods, it adds this option automatically, so I'm kinda interested to hear how you set this up to not have the option already there!

FWIW, the SchemaConfiguration file and any of your CustomScalars won't get overwritten, so you'll need to just change those manually to import Apollo instead of import ApolloAPI. (We're going to work on fixing that issue as well soon.)

Thank you very much. It is working but every time I generate I get import embeddedInTarget.Name. And it is giving error. If I comment out it everything working.

[calvincestari]

@indama I think you're using the wrong schema module type. If you're using a CocoaPods setup you need to be using .other for the schema module type and not .embeddedInTarget - this is detailed in the documentation.

This option should be used when you would like to define a schema module using another package management system, such as CocoaPods, or manually creating Xcode targets.

[calvincestari]

@AnthonyMDev we should probably get a config validation check to ensure you've got the right combination of .other when using cocoapodsCompatibleImportStatements.

Updated: #2592

[AnthonyMDev]

I don't think that's correct in all cases @calvincestari. We'll have to have a chat about this and make sure we are validating the logic properly.

[calvincestari]

1.0.2 included a fix for the first two problems we identified in this issue:

• fix: Uses correct casing for schema name in generated namespace #2586
• fix: Schema name conflict errors #2589

There is one bug left before we can close out this issue and that is the missing file; some users have indicated that pruneGeneratedFiles is causing the bug. We'll do our best to get a fix out for that in 1.0.3.

[calvincestari]

I'm closing this issue since we've addressed the initial issues and we will track the bug related to pruneGeneratedFiles in #2665 instead.