Open thomas7D opened 7 months ago
Do you also have multiple operations in the same file in your larger project?
Yes, I group related queries and mutations for the same objects in a single file.
Thanks! can you reproduce this issue when you put all operations in a separate file?
No, code is fine when I put the mutation in a separate graphql file.
I tested different variations of putting operations in single files, grouping them slightly, etc. and stumbled on this:
If I put both operations in the same file like this, I get the wrong imports prefixes:
query Pokemons {
pokemons {
id
name
}
}
mutation UpdatePokemon($id: ID!, $name: String) {
updatePokemon(id: $id, name: $name) {
id
name
}
}
If I switch them around and rerun build_runner, I get no errors in the generated files:
mutation UpdatePokemon($id: ID!, $name: String) {
updatePokemon(id: $id, name: $name) {
id
name
}
}
query Pokemons {
pokemons {
id
name
}
}
So I don't think it's related to grouping them or spreading them into separate files.
The first problem is here:
because of that typeDefNode
is always null and then isBuilder
is true and it uses replace
instead of the value assignment operator (=).
And even if originalSymbolName
would be fine, in the case of CustomDate
it still won't work, because the name of the Node is Date
(so the name of the Scalar, not the custom class we've created)
Unfortunately, I cannot find any simple way to overcome it for now π€ @knaeckeKami any tips?
Ok, I think I found a solution with the use typeOverrides
map, but I need to check it. I will back to you
Hm I am a little bit blocked.
I think the problem is that during generating schema.schema.gql.dart
file it uses 2 different allocators for input classes and input serializer classes.
I also think that the error is inside ferry_generator
package, because generating the code with the use of clean gql_builder works fine and it only breaks when using ferry_generator
.
But unfortunately, I am not so familiar with that code and cannot spot the error π€
Ok, no worries, I'll take a look at it. I also think it's related to the Allocators.
I think I found it π I can create PR soon π
Here is the fix https://github.com/gql-dart/ferry/pull/583 for the aforementioned issue (Test fails π ) and another fix is here https://github.com/gql-dart/gql/pull/448
Any updates on this? I was hoping to use tristate_optionals but this issue is currently blocking me.
@cprime Unfortunately, I haven't had time to revisit it and fix the tests yet. Currently, I am using a fork with some fixes. You can try these:
dev_dependencies:
## We use our custom version of ferry_generator with fixed `tristate_optional` feature.
ferry_generator:
git:
ref: b3c08b68cccc0f18c59b7fc816bdacb45a7303de
url: https://github.com/lilatee/ferry.git
path: packages/ferry_generator
dependency_overrides:
## We use our custom version of `gql_build` and `gql_code_builder` with somehow fixed `tristate_optionals` feature.
gql_build:
git:
ref: 7edbf44ec1c929a1ed1a9e8e79ca8949ba1ed843
url: https://github.com/LiLatee/flutter_gql.git
path: codegen/gql_build
gql_code_builder:
git:
ref: 7edbf44ec1c929a1ed1a9e8e79ca8949ba1ed843
url: https://github.com/LiLatee/flutter_gql.git
path: codegen/gql_code_builder
gql_tristate_value:
git:
ref: 7edbf44ec1c929a1ed1a9e8e79ca8949ba1ed843
url: https://github.com/LiLatee/flutter_gql.git
path: codegen/gql_tristate_value
I need to use tristate optionals for my mutations and ran into invalid code generation when enabling it.
I recreated the issue in a simple project.
The generated
test.var.gql.dart
contains errors as it's mixing up the imports when using the tristate classes.In some lines it uses the correct import
_i2
for the tristate value, in other it's wrong leading to syntax errors.I haven't figured out what causes this issue as it's not present in all cases. In the example project you can comment out the
Pokemons
query inlib/test.graphql
and the code generation works as expected. But when both query and mutation are present the code is broken.The same problems also occured in the generated schema files in a larger project when modifying that, with no obvious correlation between the changes in the schema and the mixing of imports.