This happens 😿

Given I have a graphql endpoint
And it serves a schema with comments/docs/descriptions
When I use graphql-cli to generate the schema (graphql get-schema -e default)
Then the output schema.graphql cannot be be parsed by eslint plugin and webstorm plugin

This should be happening: 🙏

Given I have a graphql endpoint
And it serves a schema with comments/docs/descriptions
When I use graphql-cli to generate the schema (graphql get-schema -e default)
Then the output schema.graphql can be parsed by eslint plugin and webstorm plugin

From a type:

# It's some sort of pet
type Pet {
  name: String
}

When generated by get-schema generates new syntax which cannot be parsed by eslint or webstorm plugins

"""It's some sort of pet"""
type Pet {
  name: String
}

Plugin versions:

ESLINT "eslint-plugin-graphql": "^1.4.1"
WEBSTORM ``JS GraphQL: 1.6.2`

Issue description

When running graphql create <directory-name>, the command will succeed only some of the time. Otherwise, it fails with an error from node.

If I repeatedly re-run graphql create it will eventually succeed.

$ graphql create test  
? Choose GraphQL boilerplate project: node-basic              Basic GraphQL server (incl. database)
[graphql create] Downloading boilerplate from https://github.com/graphql-boilerplates/node-graphql-server/archive/master.zip...
events.js:183
      throw er; // Unhandled 'error' event
      ^

Error: invalid signature: 0xa292e0fc
    at /Users/grahamb/.nvm/versions/node/v8.9.3/lib/node_modules/graphql-cli/node_modules/unzip/lib/parse.js:59:13
    at runCallback (timers.js:789:20)
    at tryOnImmediate (timers.js:751:5)
    at processImmediate [as _immediateCallback] (timers.js:722:5)

Versions

• graphql-cli 2.1.0
• nodejs 8.9.3
• macOS 10.12.6

To increase release quality, and to enable things like automerging deps.

If I have a project in my .graphqlconfig.yaml with both the Graphcool extension and the endpoints extension, the endpoints are no longer returned from the config.

Hi, I tried to upgrade this dependency but after running get-schema command I get this error:

Downloading introspection from https://graphql.kiwi.com/
✖ 
Must provide schema definition with query type or a type named Query.

It's probably because we are not using root query with the name Query but RootQuery (it works if I remove the schema completely or rename RootQuery -> Query). It seems like an unfortunate change. Not sure if it's problem of this CLI but I think this was the only change I made...

Thanks for your help... :)

As we're now using the graphql prepare command as a hook after the deploy command in the graphcool cli, it would be great to handle a non-existent .graphqlconfig more gracefully:

In other words, I would just omit any terminal output of the command, when there is no .graphqlconfig.

Ping @kbrandwijk

There seem to be a bunch of linting errors. Would be great if someone would want to fix them via a PR :)

See: https://travis-ci.org/graphcool/graphql-cli/builds/281992945#L462-L496

I just tried to install graphql-cli with a plugin (codegen but it is the same with voyager)

npm i -g graphql-cli graphql-cli-codegen

graphql -v reports 2.0.9 and seems to works ok. However, I cannot call the plugin:
graphql codegen shows the error:

Unknown argument: codegen

Am I missing something here? Thanks

It should just print the error and continue polling

I think it should be possible to use graphql get-graphql-schema to directly download a schema from an endpoint. It would also be nice if I could specify which format to use.

Something like the following:

graphql get-graphql-schema --endpoint URL --format FORMAT

I currently use the legacy project. But after I upgraded the graphcool-cli, I need to sync my local setting with remote's schema and etc. On a legacy version, I can use graphcool pull to pull the changes to local. How can I achieve the same thing in new version graphcool-cli

Any idea what going on here? Is the package not up to date?

Installing graphql-cli in the project
Added .graphqlconfig:

{
  "schemaPath": "src/schema.graphql",
  "extensions": {
    "endpoints": {
      "dev": "https://api.graph.cool/relay/v1/cj9o4se940gsu0148s5aendpoint"
    }
  }
}

added script to package.json: "schema-dev": "graphql get-schema dev",

ran yarn run schema-dev

got this error:

shingdev at cosmos in ~/code/REASON/fresh-relay-scripts
$ yarn schema-dev
yarn run v1.3.2
$ graphql get-schema dev
Can't load ./cmds plugin:Error: Cannot find module 'graphql-playground/middleware'
    at Function.Module._resolveFilename (module.js:527:15)
    at Function.Module._load (module.js:476:23)
    at Module.require (module.js:568:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (/usr/local/lib/node_modules/graphql-cli/dist/cmds/playground.js:49:20)
    at Module._compile (module.js:624:30)
    at Object.Module._extensions..js (module.js:635:10)
    at Module.load (module.js:545:32)
    at tryModuleLoad (module.js:508:12)
    at Function.Module._load (module.js:500:3)
Usage: graphql [command]

Commands:
  load [--json] [--csv] [--endpoint]        Loads data from sources using
  [--mutation] [--mapping] [--delim]        mutations using .graphqlconfig

Options:
  --version  Show version number                                       [boolean]
  --help     Show help                                                 [boolean]

Examples:
  graphql init            Interactively setup .graphqlconfig file
  graphql get-schema dev  Update local schema to match "dev" endpoint
  graphql diff dev prod   Show schema diff between "dev" and "prod" endpoints

For more information go to https://github.com/graphcool/graphql-cli

Too many non-option arguments: got 2, maximum of 1
Unknown arguments: get-schema, dev
✨  Done in 6.41s.

However, this works from command line:

get-graphql-schema https://api.graph.cool/relay/v1/cj9o4se940gsu0148s5aendpoint > ./schema.gql

It would be great if graphql-cli would always use the explicit EndpointExtension config format and not the URL-string one, and also asked for additional information like auth headers during graphql init.

When I try to run graphql ping I get this error message, which means that (of course) my authentication header is missing.

graphql ping
Sending { __typename } query to https://10-0-1-15-34134.neo4jsandbox.com/graphql/

GraphQL Error (Code: 502): {"response":{....

Unfortunately I didn’t think about looking through the graphql-config spec, so I delved into the code of graphql-cli and then graphql-config, looking for a place to add header information.
I found the code that treated the “endpoints” entries, either as URL if they are a string, or as “EndpointExtension” object otherwise, which then can also contain other information, like headers.
So I changed the entry manually into a JSON object and added my auth header information.

Based on some discussions on graphql-import, would it be an idea to add a command to the cli to process imports, and generate a resulting schema, so it could become part of build npm scripts easily, without needing any loaders? If so, what should it be called?

Also, it might be good to support schemas with imports on other commands, like lint and maybe others.

Implement commands using events

Background

As the graphql-cli ecosystem grows, and more commands are added, either to the core, or by plugins, use cases are emerging for a better way for different commands/plugins to interact with each other. This proposal addresses those use cases. It is heavily inspired by the serverless plugin system.

Command lifecycle events

Each command will define a number of lifecyle events. graphql-cli will create additional events for before and after, so for each defined lifecycle event a total of three events is generated. All of those events are executed sequentially. For example, let's take the get-schema command. This command downloads an introspection schema, and saves it to disk. It could define the following lifecycle event:

• download
  For this lifecycle events, graphql-cli would generate the following events:
• before:get-schema:download
• get-schema:download
• after:get-schema:download

Event hooks

To implement a command, you define the implementation for the lifecycle events by defining hooks. In our get-schema case, we want to implement the get-schema:download hook.

Additional events

In case of the get-schema example, there is a problem. Although download is the only lifecycle event that is triggered automatically when the command is executed, there is also functionality to update the schema when a new schema is downloaded. As this doesn't happen when the schema is unchanged, we don't want this event to be triggered automatically. But we want graphql-cli to expose events for this update step, so other plugins can hook into it. For this purpose, an 'internal' command can be defined, that can't be invoked by the user. For this, the context will expose a method: context.run('get-schema.update'). See the example below.

Hooking into existing events

In the example above, we implemented our own get-schema:download hook. However, it is possible to define an implementation for any hook from any plugin. For example, there could be a backup plugin that implements the before:get-schema:update:save hook to create a backup copy of a schema file, before it is overwritten.

Command is optional

In the current implementation, a plugin is a command. In the new system, a command is optional. This is because a plugin can hook into any event from any plugin, without defining any command of its own (like the backup example above). The plugin can also expose only internal commands, to provide hooks for other plugins.

Execution order

When different plugins are going to hook into each others events, execution order becomes important. For this, the proposal includes explicitly defining the plugins you want to use in the .graphqlconfig.yml file, so they will execute in the order defined there.

Example

Again, taking the get-schema command as example, this is what it would look like. The structure might change, because it might be possible to align it with the current yargs command structure.

export const commands = {
  'get-schema': {
    description: 'Download schema from endpoint',
    lifecycle: [ 'download' ],
    options: {
      watch: {
        alias: 'w',
        boolean: true,
        description: 'watch server for schema changes and update local schema',
      },
      endpoint: {
        alias: 'e',
        describe: 'Endpoint name',
        type: 'string',
      },
    },
    commands: {
      update: {
        type: 'internal',
        lifecycle: [ 'save' ]
      }
    }
  }
}

export const hooks = {
  'get-schema:download': download,
  'get-schema:update:save': save
}

function download(context, args) {
  if (args.watch) {
    // While true call downloadSchema, then wait
  } else {
    // Call downloadSchema
  }
}

function downloadSchema(...) {
  // Download schema
  if (schemaHasChanged) {
    context.run('get-schema.update')
  }  
}

function save(context, args) {
  // Save schema to disk
}

TODO

• Investigate yargs command file compatibility
• Define how context and args are passed in (serverless uses a class, instead of separate exports)
• ...?

[similar to #64]

1. execute graphql create foo
2. select 'minimal` template

Error (below) is generated:

[graphql create] Downloading template from https://github.com/graphcool/graphql-template-node/archive/master.zip...
[graphql create] Installing node dependencies...

(node:3202) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): TypeError: Cannot read property 'message' of null
(node:3202) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Folder structure of the created folder is:

.
├── .gitignore
├── .graphqlconfig.yml
├── README.md
├── database
│   ├── datamodel.graphql
│   └── schema.graphql
├── graphcool.yml
├── install.js
├── package.json
└── src
    ├── index.js
    └── schema.graphql

node --version
v9.2.1
graphql --version
2.1.0-beta4

get-schema --watch is a really awesome concept, but on it's own not very useful.
It would be awesome if codegen plugings could hook into it to regenerate code on a schema update.
Wdyt?

GRAPHQL_CONFIG_ENDPOINT_NAME can be set, but not GRAPHQL_CONFIG_WATCH.
Could you just accept all config with http://yargs.js.org/docs/#api-envprefix?

Issue by arthens
Thursday Sep 28, 2017 at 00:04 GMT
Originally opened as https://github.com/graphcool/cli/issues/285

Something similar to what apollo-codegen does.

Just ran into this problem because our local setup is https only but it uses self-signed certificates, which makes graphql get-chema dev fail with:

request to https://localhost/graphql failed, reason: unable to verify the first certificate

Running NODE_TLS_REJECT_UNAUTHORIZED=0 graphql get-schema dev fixes the problem, but it might be useful to have a documented option like graphql --insecure get-schema dev or graphql get-schema --insecure dev

Copied from original issue: prisma/prisma1#687

• get-schema (including --watch): Download the GraphQL schema
  • --watch
• init: Sets up a new graphql-config project using an interactive wizard
• ping
• diff: Diff two GraphQL schemas (check for breaking changes...)
• playground: Host & open local version of GraphQL Playground

Hey hey 👋

I'm tracking down a peer dependency issue in my app and it seems that it stems from graphql-cli and has been fixed in master by upgrading some packages but those changes haven't made their way to the published package on npm. Could you publish a new patch version?

I tested this command on WSL: graphql get-schema -p bahnhof -e *. On Windows, this works correctly. On Linux, I'm getting:

"database" is not valid endpoint name. Valid endpoint names: prod1, dev, test, prod2

As if getRawEndpointsMap() returns the projects instead of the endpoints.

Hi there,

New to graphql and graphcool. At a first glance i'm having trouble understanding the difference between graphql-cli and the graphcool cli projects.

Should I be using them together? If I go to the GraphCool docs for "Graphcool CLI" (https://docs-next.graph.cool/reference/basics/cli-zboghez5go) I end up npm installing graphcool@beta.

I didn't do this at first, so a simple search for graphcool cli landed me here to install a cli tool built by graphcool. I'm sure they serve different purposes, but some added clarity might help newcomers that are familiarizing themselves with the landscape.

Also, I'm seeing several dead links (Including one in the readme of this repo) pointing to "https://github.com/graphcool/graphcool-cli".

running graphcool init just blew away my existing package.json - it should check if there is already a package.json

I assume the schema returned by the GraphQL endpoint doesn't match the local schema when encoded, but is structurally identical.

That would allow use cases like checking whether dev is running, otherwise falling back to prod

Installing global binaries via NPM/Yarn can take quite a while. An increasingly popular strategy (see zeit/now) is to pre-package the CLI via webpack and distribute a single binary.

This could also be the foundation for a smarter graphql update implementation.

Running

graphql get-schema dev

with this config works:

{
  "schemaPath": "schema.graphql",
  "extensions": {
    "endpoints": {
      "dev": "http://localhost:3080/api/graphql"
    }
  }
}

but with this config (generated by graphql init):

{
  "schemaPath": "schema.graphql",
  "extensions": {
    "endpoints": {
      "dev": {
        "url": "http://localhost:3080/api/graphql"
      },
      "prod": {
        "url": "https://myserver.com/api/graphql"
      }
    }
  }
}

it just errors with

You have to specify endpoint name or define GRAPHQL_CONFIG_ENDPOINT_NAME enviroment variable

Setting the env var works, but not the command line flag.

Hi! I've experimented with my test app and worked with GraphQL schema locally in Emacs. I've changed the @relation name, launched graphcool status and got:

Project ID: cj8kamumd06qv0177zzdxv53v
Remote Schema Version: 6

Everything up-to-date.

graphcool push doesn't sync schema as well.

Is it a bug or a feature? ;)

I know this is still a work in progress but this might help maybe.

On my project I'm able to fetch my permissions but some of them seems not to have an ID and I have the following yaml

- operation: Contract.create
  authenticated: true
  query: ./query/.graphql
- operation: Contract.update
  authenticated: true
  query: ./query/.graphql

Because of that the same file ./query/.graphql is re-written for many permissions so I cannot have them all

If you want to reproduce the project id is cj4npwuofoqsc0118oels7lio and my CLI version is 1.3.8

Sorry if this is already a known bug or even already fixed

I am running the latest version of graphql-dotnet and trying to hit it via the cli's get-schema. It keeps returning the following error: Error trying to resolve type.: { long response }.

running: graphcool/0.9.2 (linux-x64) node-v8.9.1

changing existing relation (here LawOnLaw) e.g.

lawCites: [Law!]! @relation(name: "LawOnLaw")
lawCitesLaw: [Law!]! @relation(name: "LawOnLaw")

is not captured by deploy

When quickly trying out some GraphQL queries, it would be nice if there was an interactive REPL to write and send some GraphQL queries. This obviously lacks some of the great features of GraphiQL/Playground but can still be useful for smaller use cases.

It would be awesome to do this:

graphql get-schema --stdout --json | gql2ts > gqlschema.d.ts

https://www.npmjs.com/package/gql2ts#with-stdin

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because we are using your CI build statuses to figure out when to notify you about breaking changes.

Since we did not receive a CI status on the greenkeeper/initial branch, we assume that you still need to configure it.

If you have already set up a CI for this repository, you might need to check your configuration. Make sure it will run on all new branches. If you don’t want it to run on every branch, you can whitelist branches starting with greenkeeper/.

We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

Once you have installed CI on this repository, you’ll need to re-trigger Greenkeeper’s initial Pull Request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper integration’s white list on Github. You'll find this list on your repo or organization’s settings page, under Installed GitHub Apps.

• https://github.com/graphql-community/create-graphql
• https://github.com/graphcool/graphql-cli-codegen
• https://github.com/graphcool/graphql-up

Opening this in case someone has time.

GraphQL schema linter: https://github.com/cjoudrey/graphql-schema-linter/
GraphQL query linter: https://github.com/apollographql/eslint-plugin-graphql/

I couldn't find any repo or documentation on graphql create, so I'm asking it here.

Using

graphql create my-app --boilerplate typescript-advanced

I can create a new boilerplate based on typescript-advanced, at https://github.com/graphql-boilerplates/typescript-graphql-server/tree/master/advanced,

How can I create a new boilerplate based on the beta3 branch of the same repo? So, from https://github.com/graphql-boilerplates/typescript-graphql-server/tree/beta3/advanced.

Also, is there some documentation on graphql create that I missed? 🙂

The current boilerplates are a great starting point for GraphQL server development, but I want to address a couple of points that occur after the initial server is created using a boilerplate in this proposal.

Splitting generated and user code

The current boilerplates contain a single source file, containing everything to get the server up and running. While this is a great getting started experience, it's also creates a problem during further development of the server. The code can roughly be divided into two parts: user code, which is mainly the implementation of the resolvers, and any other custom code, and the plumbing around it. I think it would be a good next step to split these up into two different files. This paves the way for the next steps in this proposal.

Adding endpoints

Whenever a new endpoint is added to the server, it ends up as a 'project' in .graphqlconfig (we might want to rethink the term 'project'). Next, a new binding has to be added to the server context (and optionally pre-generated). This is currently a manual step. It would be great if when adding an endpoint to the server, it would be possible to update the server code to add another binding to the context. Having no user code in that file will help with this.

• TODO: Create an example based on current boilerplate

Knowing the endpoint address

In the current setup, I don't see a way to easily retrieve Graphcool endpoint addresses. They are not part of graphcool.yml, and there is a relationship to environment variables, stages, etc. At the end of the story, the endpoint address needs to end up in the server file for the binding to work.

• This point needs further detailing

Refreshing schemas

When using either compile-time bundling (processing schema imports) or generated binding files, there should be an easy way to regenerate those when a schema is refreshed. There are a few different actions that can trigger this, and we need to think about a way to detect those. For Graphcool services, there's graphcool deploy that downloads the new backend schema. For 'custom' endpoints, there's graphql get-schema and when using GrAMPS, adding a new datasource, or updating a datasource package, would cause a new schema.

Bottom line is, the getting started experience is great, but I think we can provide additional tooling during the development phase to make the inception to production experience even greater.

cc @schickling @jlengstorf @marktani

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because we are using your CI build statuses to figure out when to notify you about breaking changes.

Since we did not receive a CI status on the greenkeeper/initial branch, we assume that you still need to configure it.

If you have already set up a CI for this repository, you might need to check your configuration. Make sure it will run on all new branches. If you don’t want it to run on every branch, you can whitelist branches starting with greenkeeper/.

We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

Once you have installed CI on this repository, you’ll need to re-trigger Greenkeeper’s initial Pull Request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper integration’s white list on Github. You'll find this list on your repo or organization’s settings page, under Installed GitHub Apps.

graphql-cli doesn't seem to support multi project configurations like this:

{
  "projects": {
    "database": {
      "schemaPath": "database.graphql",
      "extensions": {
        "endpoints": {
          "default": {
            "url": "https://api.graph.cool/simple/v1/xxx",
            "subscription": "wss://api.graph.cool/simple/v1/xxx"
          }
        }
      }
    },
    "gateway": {
      "schemaPath": "gateway.graphql",
      "extensions": {
        "endpoints": {
          "dev": {
            "url": "http://localhost:4000",
            "subscription": "ws://localhost:4000"
          }
        }
      }
    }
  }
}

Error message:

It should be possible to provide the project name via a --project argument.

(node:938) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): Error: [ERROR] in /Users/state0fmind/Projects/GitHub/blogr/graphcool.yml: Errors while validating graphcool.yml: data should have required property 'stages'

(node:938) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.