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

Apollo 1.0.x generate multiple files with the same name in the same package #2645

Closed
Dimillian opened this issue Nov 7, 2022 · 8 comments
Closed

Comments

@Dimillian
Copy link

Dimillian commented Nov 7, 2022

Here is our configuration with Apollo 1.0.3

let configuration = ApolloCodegenConfiguration(schemaName: "GQL",
                                               input: .init(schemaPath: urlToSchemaFile.absoluteString),
                                               output: .init(schemaTypes: .init(path: outputURL.absoluteString,
                                                                                moduleType: .other),
                                                             operations: .inSchemaModule))

I'm using other as moduleType and inSchemaModule because we're already having a package ready to accept the code generated by GraphQL. And we want all the GQL code to be within this package.
Using 0.5.X it was working fine, new codegen split the files using the same file name in different folders, this is not something that is supported in a Swift Package or even the targets in Xcode.
Xcode fail to compile it with those kind of errors

image

@calvincestari
Copy link
Member

Hi 👋🏻 - do you have different GraphQL items, such as Object, Fragment, Interface, etc., all sharing the same name? If not, what are those types of items that get the same filename?

@Dimillian
Copy link
Author

Yes, that's the issue, I have those folders with the same files file names within.

@calvincestari
Copy link
Member

Hmm, I'm not sure what the right solution is here. I don't want to have to suffix every generated item with it's type and there's already too many configuration options to support an option per type. This needs more thought.

Using 0.5.X it was working fine

Was your previous code being generated into just one file before?

@calvincestari calvincestari added this to the Release 1.0.4 milestone Nov 7, 2022
@Dimillian
Copy link
Author

We were using the JavaScript CLI and we were splitting it in different files but there was no overlap in naming.

@Dimillian
Copy link
Author

I do think file prefix or suffix sound fine. It needs to be worked around because it can't work in the current way with the compiler. I don't think I'm doing anything exotic with our configuration?

@calvincestari
Copy link
Member

We were using the JavaScript CLI and we were splitting it in different files but there was no overlap in naming.

What were the filenames for these same objects before when using the JS CLI?

I do think file prefix or suffix sound fine. It needs to be worked around because it can't work in the current way with the compiler. I don't think I'm doing anything exotic with our configuration?

It's the schema types that have duplicate filenames right? The schema is the source-of-truth for those and there is no way to alias a type. IMO a better practice is not to name so many things the same but as someone building a client app you may not have control over the schema and type names. So it really has to be the codegen engine that works around it.

@Dimillian
Copy link
Author

Awwwwww I just got it! Yes we indeed have two fragments named the same as one of out schema type. Usually we append data at the end to be sure it'll not collide. I guess we missed those two because the previous codegen was collapsing all of it into one file. Let me check what it was outputting once I'll be back on it.

So I guess a warning in the codegen debug console could be fine.

@calvincestari
Copy link
Member

Suffixing "Fragment" to the end of fragment names/filenames is something we're already considering. I'm going to close this issue as a duplicate of #2598, you can track it's progress there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants