0no-co / gql.tada

🪄 Magical GraphQL query engine for TypeScript
https://gql-tada.0no.co
MIT License
2.44k stars 34 forks source link

gql.tada check erroneously reports field not in use in Vue SFC. #323

Closed JarvisH closed 6 days ago

JarvisH commented 3 weeks ago

Describe the bug

Using the official Pokemon example for Vue:

 example-pokemon-vue git:(main) ✗ npx gql.tada check
⚠ Note: .vue and .svelte file support is experimental.

src/components/PokemonTypes.vue
  7:5   warn    Field types is not used.

src/components/PokemonItem.vue
  9:7   warn    Field name is not used.

The name field is reported as not being in use. Here is the template in question, were we can see <p>{{ pokemon.name }}</p> in use in the template.

<script setup lang="ts">
import { FragmentOf, readFragment } from "../graphql";
import { ref, computed } from "vue";

const props = defineProps<{
  data: FragmentOf<typeof PokemonItemFragment> | null;
}>();

const pokemon = computed(() => readFragment(PokemonItemFragment, props.data));
</script>
<template>
  <li v-if="pokemon">
    <p>{{ pokemon.name }}</p>
    <PokemonTypes :data="pokemon" />
  </li>
</template>

Any fields referenced inside <script setup> are recognized however, only references inside <template> are ignored.

Reproduction

No response

gql.tada version

gql.tada 1.7.6

Validations

JoviDeCroock commented 3 weeks ago

Yeah, after the Vue compiler runs there's some weird wrapping on all the properties and we can't infer usage anymore. My best recommendation for now is to turn of field usage tracking in vue, maybe we should just turn it off for SFC 😅

JarvisH commented 3 weeks ago

gql.tada is really cool, and using it seamlessly with Vue would be great. I know everything is still in an early phase so I completely understand if this is not a priority right now. Do you feel that long term complete Vue-Integration is possible?

kitten commented 1 week ago

only references inside <template> are ignored.

I think this is potentially not possible unless the transform always outputs the complete template code as TypeScript code as well.

We did try to figure out more heuristics to mark an entire fragment subtree as unused. But we'll potentially have to simply disable these checks for vue files and svelte files in the future, I suppose, since there may not be enough info to go on otherwise 🤔 I wouldn't exclude this from being possible, but it just seems pretty hard without a simpler heuristic that just excludes used subtrees.

The warning is there to basically help on migrations mostly. In an ideal world it should always remain evident which fields are used or not given a simple, co-located fragment. So, if it's causing you any issues, I don't think you'd lose out on much when disabling it tbh