Is it possible to use this with watch mode?

[mhaagens]

I've tried setting watch: true and passing a -watch flag, neither seem to work.

[piglovesyou]

Hi. I suppose users achieve incremental builds through webpack HMR. If you don't want webpack, I simply suggest using codegen.yml and GraphQL code generator's watch mode.

[sahilrajput03]

I've tried setting watch: true and passing a -watch flag, neither seem to work.

First of all do

yarn add -D nodemon npm-run-all

I faced the same issue and i made a solution for myself and it works pretty neatly, thanks to npm-run-all and nodemon. Now, npm run dev or yarn dev works like expected!! And good thing is that graphql-let only gets executed when changes are made in .graphql or .graphqls extension files.

You can find it done in my repo here.

The original example was from next.js's with-typescript-graphql example.

Thanks

[acao]

@mhaagens a high performance option is watchexec which is written in rust:

yarn add --dev watchexec-bin

for serial execution on file change:

"start": "watchexec --exts js,jsx,ts,tsx,graphql 'yarn graphql-let && yarn build'"

for parallel execution on file change:

"start": "watchexec --exts js,jsx,ts,tsx,graphql 'yarn graphql-let; yarn build'"

the last two commands being whatever command you want to run when something changes.

also, to note, running simultaneous watchexec instances for different file extensions is highly performant!

[piglovesyou]

I don't still get in which scenario we need watch mode in graphql-let CLI. The CLI only generates .d.ts basically, not runtime source code, which Babel or webpack will generate. If you use Babel or webpack, you can use their watch mode or HMR. Are .d.tss enough for you!?

[sahilrajput03]

I don't still get in which scenario we need watch mode in graphql-let CLI. The CLI only generates .d.ts basically, not runtime source code, which Babel or webpack will generate. If you use Babel or webpack, you can use their watch mode or HMR. Are .d.tss enough for you!?

Really ? Consider this case, I edit the the type-defs.graphqls file and then I edit my resolvers.ts file which uses QueryResolvers from type-defs.graphqls.d.ts file and I want to see the updated types(from typescript) in my resolvers there which don't show the typings coz the QueryResolvers in type-defs.graphqls.d.ts is not generated by graphql-let yet and thus typings(from typescript) are not updated. So in such case one needs the watch mode for graphql-let, am i clear enough ?

@piglovesyou

[piglovesyou]

Thank you, you're right. It was always in my mind that GraphQL code generator generates .tsx containing implementation, but there can be a case to use only type declarations like yours.

Now the PR would be like this.

• [ ] Let's have the file watcher library (whatever it is) be in peerDependencies. It'd be something requiring gyp build, which could be troublesome sometimes, which non "--watch" users are unhappy with.
• [ ] The explanation of the use-case is in the README.md with what it doesn't cover.
• [ ] (What else do you have in your mind?)

[sahilrajput03]

@piglovesyou It not about types in .ts files only but the generated queries as well. I mean the queries should be generated with watch mode as well. The third message on this issue I commented with best solution so far possible, if you haven't seen that please look at that.

In that I am specifying with script codegen-w that if any file with extension .graphql or .graphqls are modified then run the graphql-let binary and that is exactlt what I(some others) want.

Also, i have used the run-p(package: npm-run-all) to run my next dev server parallely with the codegen-w script. And it works AWSOME, try it on the repo i linked there if you are interested.

Fyi: I am happy with my current solution. May be the PR can use the same nodemon solution and add nodemon as peer dependency and use the same command to watch for the .graphql and .graphqls file ane run on every those changes.

What do u think..?

[piglovesyou]

Thanks for adding it. Okay, now I'm confused again. Don't worry about "how to detect file modification"; it's not the problem. Let's keep "why the graphql-let CLI has to have a watch option" talking.

You'd like not only types (all omitted on runtime) but implementations (being compiled by Babel or Webpack). The thing is, all syntax that graphql-let provides and generates implementations requires code compilation to be run, in addition to graphql-let code generation.

Example. Suppose you use graphql-let in webpack. Your code would have these lines:

import { useViewerQuery } from './viewer.graphql';

useViewerQuery()

Here, the graphql-let CLI is not enough to run this code; you need to run it inside a webpack compilation context, yes? My question is, we need webpack to run code, and even though webpack-cli has the sweet --watch option, why we still want graphql-let to have the option too?

[sahilrajput03]

Here, the graphql-let CLI is not enough to run this code; you need to run it inside a webpack compilation context, yes?

My ans. YES!!!

My question is, we need webpack to run code, and even though webpack-cli has the sweet --watch option, why we still want graphql-let to have the option too?

My ans. I'm not sure if webpack/babel can generate these queries (i.e., useViewerQuery ) at runtime when I add a new field or say remove a filed from the query in .graphql or .graphqls file, can it?? I think NO, only graphql-let can update the code for queries like useViewerQuery by executing the graphql-let from the command line.

@piglovesyou , conversation is going interesting now.!!

What is the phase do we call when me or anybody would write code in .graphql or .graphqls file ??

Thats development time, right...?

What is the phase do we call when me or anybody would write code in .js or .ts file and we import the magical queries made by grahpql-let like below:

import { useViewerQuery } from './viewer.graphql';

useViewerQuery()

??

That's development time, again, right...?

When me or anybody in development time, nobody would like to write query in .graphql and .graphqls and followed by running the graphql-let on each minor/major change in these files. Thus, its just a better development experience if graphql-letjust continuously watches for file changes in .graphql and .graphqls files at the time of development phase, thus saving time and having magical experience with graphql-let, without ever executing graphql-let more than once when we are just adding lots and lots of changes in the resolvers and the schema and the query (in .graphql and .graphqls files) itself.

From the start of conversation you are saying webpack/babel will watch for runtime changes in the code, but of all what i know aobut graphql-let and graphql-codegen, the work of each of these tools is about providing statically tooling or statically generated code. Only after these tools finish the statically generating code, we are supposed to run the code where webpack/babel actually comes to role play.

[piglovesyou]

Thanks a lot again. I think you're right, mostly.

In short, webpack HMR detects file change of the ./viewer.graphql on our behalf. It's a tested scenario. Also, babel --watch detects your *.tsx change, which emits our plugin or macro to regenerate too.

A single process detecting file changes is enough. You don't want to run both webpack serve and graphql-let --watch, do you. So currently, I think webpack serve is enough, or moreover, it should do all.

[acao]

Agreed @piglovesyou ! This is our greatesr draw to graphql-let, so we can just leverage the webpack file watcher now!

[sahilrajput03]

Thanks a lot again. I think you're right, mostly.

In short, webpack HMR detects file change of the ./viewer.graphql on our behalf. It's a tested scenario. Also, babel --watch detects your *.tsx change, which emits our plugin or macro to regenerate too.

A single process detecting file changes is enough. You don't want to run both webpack serve and graphql-let --watch, do you. So currently, I think webpack serve is enough, or moreover, it should do all.

I dont know if its a silly question but I want to ask "react-scripts start" and "next dev" should also be expected to watch for the changes in '.graphql' and '.graphqls' files as well?? As i tested earlier it was not working with either of them IIRC!... 🧐

[piglovesyou]

Thank you @acao, good to hear that!

@sahilrajput03, thanks, now I see why you want a --watch option. Would you mind making another issue of when file detection fails?

[sahilrajput03]

Thank you @acao, good to hear that!

@sahilrajput03, thanks, now I see why you want a --watch option. Would you mind making another issue of when file detection fails?

Sure..!! 🙂 I'll make a new repo to replicate the faulty behaviour!!.

[sahilrajput03]

Oh god!! @piglovesyou , I am really sorry for all that, I see now this works pretty well🚀︎🚀︎. BOTH TYPES AND QUERY CODE IS UPDATED WITHOUT ANY WATCH MODE...!!!

I tested it and even recorded it.! Check it out in a video here. graphql-let is amazing!! 🥰︎🥰︎

@mhaagens , I would request you to check if it works for you too..??

I would request @mhaagens to close the issue if it works there as well !!

Source of the repo used: https://github.com/sahilrajput03/with-typescript-graphql

[piglovesyou]

No problem at all. Thank you for taking your time to try it out.

Let's keep this open. I came up with scenarios wanting watch mode.

1. If you don't use Babel nor webpack, they'll want it, especially in the case as described in https://github.com/piglovesyou/graphql-let/issues/479.
2. If you use Babel and load() macro, *.graphql doesn't emit Babel file change detection since Babel only watches *.ts(x). Please let me know the solution if you have.

I appreciate it if you give me a --watch PR to solve them.

[sahilrajput03]

No problem at all. Thank you for taking your time to try it out.

Let's keep this open. I came up with scenarios wanting watch mode.

1. If you don't use Babel nor webpack, they'll want it. I think it's possible in the case as #479 describes.

2. If you use Babel and `load()` macro, `*.graphql` doesn't emit Babel file change detection since Babel only watches `*.ts(x)`. Please let me know the solution if you have.

I appreciate it if you give me a --watch PR to solve the 1.

It can take a while to do so as I just started a job in a company. I am interested in this though. :)