Disallow a target name of apollo when using a module type of embeddedInTarget(name:)

[moopoints]

Summary

I'm running into the same issue as previously reported here:

The suggestion offered by Calvin in issue #2859 isn't working for me - the SchemaNamespace isn't accessible either.

Environment

• Xcode 14.2
• Apollo iOS 1.1.2

Version

1.1.2

Steps to reproduce the behavior

• Brand new SwiftUI project using Xcode 14.2
• Add Apollo SDK via SPM
• Add schema.graphls, set up config, generate
• Add files to Xcode project
• Attempt to access either TestAPI (SchemaNamespace) or any Query

Here is a link to a sample project very closely following the setup instructions provided here.

Logs

No response

Anything else?

https://share.cleanshot.com/WZ52Fdkw

Tasks

Preview Give feedback

No tasks being tracked yet.

[calvincestari]

Hi @moopoints, apologies for taking a while to get back to you. Thanks for attaching a sample project, it's certainly helpful to be able to take a closer look at these sorts of issues that way.

There's a couple issues with the way the Xcode project is set up that is causing this:

1. It doesn't look like the FrondSchema folder was correctly added to the project. None of the source files it contains is being compiled into the target - screenshot. I removed the FrondSchema folder from the project, re-added it and now all the generated types will be compiled into the target - screenshot
2. Doing that still won't resolve the build errors because the target is named the same as the library being imported - Apollo. They cannot be named the same. Once I renamed the target and re-added the FrondSchema folder the project builds without error. @AnthonyMDev - we may need to consider adding this to our list of reserved words for schema/target to prevent this in the future.

Here's an archive of the project that builds with git history so you can see the changes - link

[AnthonyMDev]

@AnthonyMDev - we may need to consider adding this to our list of reserved words for schema/target to prevent this in the future.

Yes, that seems like a good idea. Thanks for taking a look at this @calvincestari

[moopoints]

Appreciate it @calvincestari.

re-added it and now all the generated types will be compiled into the target

Is there a trick to how you're adding these files to make sure they're added to the compile sources and how do you recommend handling this each time one regenerates the files after updating queries?

[calvincestari]

Is there a trick to how you're adding these files to make sure they're added to the compile sources

No, nothing special in how they're added to the project: right-click on the project folder that I want them added to, select "Add files to ...", select the folder to be added, and ensure that the correct target is selected (this is what adds them to the "Compile Sources" build phase).

how do you recommend handling this each time one regenerates the files after updating queries?

This is where careful selection of the moduleType property for code generation comes into play.

• By choosing embeddedInTarget you're stating that you will be responsible for management of the generated files. So if you have already added a generated file to your project it will simply be updated upon regeneration but still a part of the project. However if a new file is generated you will need to manually add it to the target before it can be compiled into your project.
• You can get the benefit of some module automation through the swiftPackageManager setting because codegen will maintain that package and all files will be included on each regeneration.
• The other setting still has some automation but is a more manual version of package management.

[calvincestari]

I'm reopening this issue and have renamed it to better reflect the work to be done, which is resolving point 2 in this comment.

2. Doing that still won't resolve the build errors because the target is named the same as the library being imported - Apollo. They cannot be named the same. Once I renamed the target and re-added the FrondSchema folder the project builds without error. @AnthonyMDev - we may need to consider adding this to our list of reserved words for schema/target to prevent this in the future.

The work involved is probably where we validate ApolloCodegenConfiguration values and also in the CLI where we accept the target name from the command line. This should cater for feedback to the user during codegen configuration initialization and usage.

[calvincestari]

@BobaFetters this is an issue to dip your feet into some parts of the codegen engine, if it's something that interests you.