-
Notifications
You must be signed in to change notification settings - Fork 55
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
Importing named type conflicts with import * from same file, depending on order of imports #182
Comments
Another bit of info - This fix only works in version 0.5.2 If I upgrade to 0.6.0, the |
I have the same problem and found out what's going on. if (!processedFiles.has(moduleFilePath)) {
collectDefinitions(
m.imports,
read(moduleFilePath, schemas),
moduleFilePath,
schemas,
processedFiles,
typeDefinitions,
allDefinitions,
)
} Here, we check if the file has already been imported, which is good. To fix that, we should check for the file and the named imports given. This will probably be a bit tricky with But I can try to open a PR for this. |
@EmrysMyrddin That's definitely the sort of piece of code I assumed existed somewhere! |
@schickling thoughts on this? @EmrysMyrddin has a proposal PR open that would fix this issue |
I'm only seeing this issue now but PR #213 will fix this too. |
Hi @jessicaxp ! Let us know if the problem persists. |
I'm using type extension in my project and just ran into an issue that took me a while to figure out. I was following along with the comments in Type extension does not work and found an issue where importing named vs. wildcard types from the same file can result in the wildcard import being clobbered, based on the order that the referencing items are imported.
Consider the following type definitions:
SomeType.graphql
Mutation.graphql
Query.graphql
If the definition using the named import is imported first, as in this example:
Schema.graphql
Running this code will return an error
"Mutation" defined in resolvers, but not in schema
However, if the definition using the wildcard import is imported first, as in this example:
Schema.graphql
The code will run fine.
I imagine there's some filename-based caching or de-duping going on. Not sure whether this is intentional behavior, but if it is I'd recommend clarifying in the import documentation.
The text was updated successfully, but these errors were encountered: