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

Naming collision with DocumentType in generated mock code #2719

Closed
dafurman opened this issue Dec 10, 2022 · 2 comments · Fixed by #2762
Closed

Naming collision with DocumentType in generated mock code #2719

dafurman opened this issue Dec 10, 2022 · 2 comments · Fixed by #2762
Assignees
Labels
bug Generally incorrect behavior codegen Issues related to or arising from code generation planned-next Slated to be included in the next release

Comments

@dafurman
Copy link

Bug report

This is similar to #2708 but it only concerns mocks, so it seemed worth treating as a separate issue.

I have a enum type DocumentType that conflicts with ApolloAPI.DocumentType in generated mock code.
Would it be possible to prefix generated types in mocks with the schemaName they're living in to resolve ambiguity?

Versions

Please fill in the versions you're currently using:

  • apollo-ios SDK version: 1.0.5
  • Xcode version: 14.1
  • Swift version: 5.7
  • Package manager: Swift Package Manager

Steps to reproduce

To reproduce this you will have to use a scheme that defines DocumentType as an enum type.

Further details

Screen Shot 2022-12-09 at 6 02 50 PM

#2679 seemed to fix this issue for the main generated code, but I'm still experiencing this issue for generated mocks.
If I manually specify the type as coming from my generated package - GQLTypes, I can get the mocks compiling successfully:

public struct MockFields {
    @Field<GraphQLEnum<GQLTypes.DocumentType>>("documentType") public var documentType
}
@calvincestari
Copy link
Member

Thanks for creating the issue @dafurman. @AnthonyMDev and I are working on resolving these type name conflicts once and for all. We'll get these resolved.

@calvincestari calvincestari added bug Generally incorrect behavior codegen Issues related to or arising from code generation labels Dec 10, 2022
@calvincestari calvincestari added this to the Release 1.0.6 milestone Dec 10, 2022
@calvincestari calvincestari added the planned-next Slated to be included in the next release label Jan 5, 2023
@calvincestari calvincestari self-assigned this Jan 5, 2023
@calvincestari
Copy link
Member

@dafurman, apologies for the delay in this issue but it is now fixed, merged and will go out in the next release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Generally incorrect behavior codegen Issues related to or arising from code generation planned-next Slated to be included in the next release
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants