Closed raphael-yapla closed 4 months ago
kitten
commented
4 months ago Does that actually work in a regular tsc run or not?
I'm not super familiar with how Volar works, but for our check command that definitely won't just work out of the box.
See:
raphael-yapla
commented
4 months ago No you'd have to use vue-tsc so that would makes sense.
The only thing I don't understand is how comes the check command works when importing to and from a Vue SFC file then?
JoviDeCroock
commented
4 months ago Yes, both for Svelte and Vue we could use their respective packages to do a prepass over all the files and make them into TS
Then add the TS equivalent of these files into ts-morph and run check - that being said for now these are open RFC's. I do think for the CLI we'll need to tackle this a bit differently than for the LSP. The LSP essentially will become a VSCode plugin/TSLang plugin built on volar if we want to support all these SFC formats.
From what I can tell we can even patch how TS gets its script snapshots, maybe that is a better solution for this as it would solve both the CLI and TS Plugin https://github.com/sveltejs/language-tools/blob/master/packages/typescript-plugin/src/index.ts. The volar way looks a lot simpler though https://github.com/vuejs/language-tools/blob/master/packages/typescript-plugin/index.ts
kitten
commented
4 months ago @JoviDeCroock Just to note this down somewhere, TS Morph seems to have an open issue for this but hasn't resolved this yet, but someone there basically pointed out the API to use for this on the TS side
kitten
commented
4 months ago Another comment here on this topic: https://github.com/0no-co/gql.tada/issues/231#issuecomment-2065455186
The gist of it is though that currently we have no timeline or implementation path yet for Vue, Astro, and Svelte support, and haven't deprioritised this yet
JoviDeCroock
commented
4 months ago I have an initial working version for this in #232 - would love for this to be tested on larger projects though 😅
KammererTob
commented
4 months ago I have tested the PR on my project, which contains >70 fragments and queries in various files (mostly .ts and .vue file), with nested fragments etc. The cache is now correctly populated, but it seems to break some typings (as far as i can tell only for fragments/queries which contain a fragment of another component). Here is an example (left without cache, right with cache).
"\n fragment EventDialog on Event {\n id\n name\n platform\n discipline\n ...EntityEditDialog\n }\n ": TadaDocumentNode<{ [x: string]: any; }, {}, { fragment: "EventDialog"; on: "Event"; masked: true; }>;
If you need more information please let me know. I can also try to reproduce this in the reproduction i've provided in the linked issue if helpful.
JoviDeCroock
commented
4 months ago Was able to fix check and generate persisted but turbo is still a pain, looks like the type-checker isn't really willing to collaborate here 😅
EDIT: all fixed, we'll prepare this as an experimental feature
raphael-yapla
commented
4 months ago Incredible, thank you so much for such a quick turnaround!
Describe the bug
We're trying to setup gql.tada to do a check in a CI job using the newly added check command (awesome addition btw!) but we're faced with a weird issue. The command will report incorrectly an error when fragments are imported from a different file type. This is what I've tested:
The IDE however, is fine with any kind of combination. I'm unsure where the problem lies exactly but it seems strange that the IDE would not report the error if both the CLI and IDE are using the LSP?
I've set up a reproduction that hopefully will help you track the source down.
Thank you so much for the awesome project, it might be the best package I've used in a long time!
Reproduction
https://github.com/raphael-yapla/gql-tada-vue-issue
gql.tada version
gql.tada v1.5.0
Validations