Graphql-code-generator: Wait for previous generate?

[sarink]

generates:
  ./src/api-schema.json:
    schema: http://localhost:3000/api/graphql
    plugins:
      - introspection

  ./src/api-queries.ts:
    schema: ./src/api-schema.json
    documents: src/queries/*.ts
    plugins:
      - typescript
      - typescript-operations

This will fail, because both operations execute simultaneously. Is there any way to wait for the schema.json to download and then use it to generate the queries? I know I could just put the url of the service in the second schema too, but I need the schema.json for eslint and I prefer for frontend code to not require the backend services to be running to generate their types

[dotansimha]

@sarink You don't have to load the schema into a file and then load it, you can use the endpoint directly in both cases:

schema: http://localhost:3000/api/graphql
generates:
  ./src/api-schema.json:
    plugins:
      - introspection

  ./src/api-queries.ts:
    documents: src/queries/*.ts
    plugins:
      - typescript
      - typescript-operations

[sarink]

I know I could just put the url of the service in the second schema too, but I need the schema.json for eslint and I prefer for frontend code to not require the backend services to be running to generate their types

Is there any other way? I wan to ensure that the schema.json in the repo is always up to date.

[dotansimha]

Currently, there is no way to have dependencies between different file outputs, mainly because each output is independent and we run it in parallel.

@kamilkisiela What do you think? you think we can do solve that with listr?

[ardatan]

@dotansimha We can change concurrency limit to 1 so they would block and wait for each other in sync way.

[dotansimha]

@ardatan yeah this could work, but still we need to manage order or execution somehow

[ardatan]

@dotansimha This needs to be tested properly. Since listr takes an array and iterates over jobs to execute them. If there is no concurrency, it would respect the order of job. But I am not 100% sure

[ardatan]

@dotansimha check this https://www.npmjs.com/package/listr#concurrent

[dotansimha]

@ardatan yeah but still, if the order of keys under generates will be different , it won't work, because we need to understand the dependencies between the outputs.

[ardatan]

@dotansimha yes you're right we cannot trust JavaScript objects. Map can be used there to keep the order of keys.

[dotansimha]

Also, @ardatan suggested that you'll try to use the programatic API and generate things in order.
At the moment, we do not plan to add a way to create dependencies between outputs.

[kamilkisiela]

@dotansimha @ardatan we could collect keys and iterate over schema and documents to look for it, then with dependency-graph, we have a nice solution. When it's a glob, then we check if it matches. It's not expensive but may help a lot.

[kamilkisiela]

@dotansimha @ardatan @sarink
https://github.com/dotansimha/graphql-code-generator/pull/3603

[dotansimha]

Fixed in v1.13.1 🎉

[sarink]

@ardatan @dotansimha can you explain how this is supposed to work?

generates:
  ./src/api-schema.json:
    schema: http://localhost:3000/api/graphql
    plugins:
      - introspection

  ./src/api-queries.ts:
    schema: ./src/api-schema.json
    documents: src/queries/*.ts
    plugins:
      - typescript
      - typescript-operations

This is still not working for me. I also tried making each of the keys an array (ie, - ./src/api-queries.ts), but that had no effect either. I'm confused.

I would've thought that there would be two possible solutions to this:
1) Letting the value of generates be an array of jobs to execute in order
2) If the value of a schema matches a key of generates (ie, ./src/api-schema.json in this case), it would wait for that job to be completed first

[sarink]

Bump? #3603 looks like @kamilkisiela put a lot of work into this, I'd love to be able to use it!

[kamilkisiela]

@sarink we reverted it because generation happens before CLI persists the output to file system, so it awaits forever or completes before we save anything to disk. I could work on it but not in next week or two.

[sarink]

Ah, I see, that explains it. Thanks :)

[ardatan]

@sarink In the meanwhile, I recommend you to use programmatic API to generate each file by synchronously waiting each other