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

gql.tada turbo doesn't generate cache for documents in Vue SFC files #231

Closed
3 tasks done
KammererTob opened this issue Apr 18, 2024 · 1 comment · Fixed by #232
Closed
3 tasks done

gql.tada turbo doesn't generate cache for documents in Vue SFC files #231

KammererTob opened this issue Apr 18, 2024 · 1 comment · Fixed by #232

Comments

@KammererTob
Copy link

Describe the bug

It seems like gql.tada turbo does not work with Vue SFC files. Cache entries in my project are only generated for normal typescript files, but none for any documents defined in my components.

See the reproduction provided for a minimal example. The graphql-cache.d.ts file only contains the query of random.ts, although there is another query defined in PokemonList.vue.

Maybe i misunderstood something, but i assume that those should be generated as well?

Thank you!

Reproduction

https://github.com/KammererTob/gql.tada-turbo-bug/tree/main

gql.tada version

gql.tada v1.5.3

Validations

  • I can confirm that this is a bug report, and not a feature request, RFC, question, or discussion, for which GitHub Discussions should be used
  • Read the docs.
  • Follow our Code of Conduct
@KammererTob KammererTob changed the title gql.tada turbo doesn't generate out of Vue SFC files gql.tada turbo doesn't generate cache for documents in Vue SFC files Apr 18, 2024
@kitten
Copy link
Member

kitten commented Apr 18, 2024

Duplicate of #210

I know that looking at the two exactly, they don't seem similar at first glance but the tl;dr is that Vue, Svelte, Astro, and similar files cause a lot of problems to the tools around them and specifically in TypeScript's case it doesn't have support built in.

This is still something we'll look at but we haven't figured out where it falls into our priorities yet after @JoviDeCroock did some initial investigation work and tried to build a proof of concept.
This is further complicated by this having to be done for two or three separate APIs with separate implementations:

  • a new custom TS program wrapper to replace what the CLI uses
  • an LSP API wrapper that is proving to be rather error prone
  • and/or Volar being used and the LSP becoming a plugin for it as an alternative to the above. However, at least one of the tools above has moved away from Volar afaik and there are some rather consequential DX implications here

But in short, the other issue is essentially the same from an implementation perspective

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

Successfully merging a pull request may close this issue.

2 participants