GraphQL Config + GraphQL CLI

[samuelcastro]

It'd be great to use graphql-config with graphql-cli to take advantage of the code generation for type schemas through package.json scripts rather than using IDEs config (webstorm/vscode/etc), this would improve the development workflow quite a lot.

Also, I'm having a hard time trying to integrate graph-config on vscode, since they're released a brand new version recently I can't find a vscode extension that properly works with it, having a script to generate the schema and types would be super helpful.

https://github.com/stephen/vscode-graphql/issues/27 https://github.com/kamilkisiela/graphql-config/issues/555 https://github.com/Urigo/graphql-cli/issues/1249

We could do something like:

schema: 
  - https://graphcms-url:
      headers:
        Authorization: key
extensions:
  codegen:
    generates:
      ./schema.graphql:
        plugins:
          - schema-ast
        config:
          commentDescriptions: true
      ./src/common/types/data/DataTypes.tsx:
        plugins:
          - typescript
          - typescript-operations

and then

"scripts": {
   "codegen": "npx graphql-codegen"
}

With this in place we won't need to maintain our own types (GraphCMS) since everything will be pulled out directly from the source. (Single Source of Truth)

Also we need to migrate the .graphqlconfig file to the new graphql-config structure.

[samuelcastro]

Btw, I'd be happy to provide a PR, I already have a working setup that generates the schema.graphql as well as ts types.

[Vadorequest]

I'm not so keen on removing something that works perfectly fine using a no-code/config approach such as https://github.com/jimkyndemeyer/js-graphql-intellij-plugin. This would definitely be a regression for webstorm users.

Also, your proposal doesn't mention how we're supposed to manage multiple sources (staging/production), that's something the current setup provides (I believe it can be done using https://github.com/kamilkisiela/graphql-config, but I don't know how much time consuming it is)

Same goes for secrets, the plugin offers a way to prompt an input to get its value, and thus avoid storing sensitive secrets within files that are tracked by git.

I'd prefer to keep the WebStorm plugin. I understand the need for VSCode users though, and eventually it's a matter of personal taste.

I'm not technically against proposing an alternative, but I'd like it to be as close as possible as the current one, and avoid functional regressions such as "secrets" and "multiple sources" as mentioned above.

Also, I'm personally moving away from GraphQL (hugely working on https://github.com/UnlyEd/next-right-now/pull/86) and I'll have little time to review a PR.

The documentation should also be updated to mention the two different ways of generating the GraphQL schema.

[Vadorequest]

The idea of generating TS types automatically is appealing though, I had missed that part of the proposal.

[samuelcastro]

Out of curiosity, why are you moving away from GraphQL?

[Vadorequest]

It's due to business constraints/needs mostly. Stacker with Airtable is a really great combo to quickly provide a CMS to manage data that is flexible and usable by non-technical people.

GraphCMS (and GraphQL in general) is too technical/complex to my taste, it's great, but requires quite a deep knowledge and time to get right.