It seems nice to support using language server protocol file watch events over watchman when it's available.

This would mean that extensions wishing to use the service would not have to additionally install watchman through some other delivery channel.

This is a bug that shook out the refactoring to make watchman optional #218. If watchman is installed on the user's system, we need to subscribe the loaded project or projects from .graphqlconfig to file change events. However, it looks like in the case where the .graphqlconfig didn't define any projects, that is, it just contains top-level data about the project, this line blows up because config.getProjects returns undefined.

The simple fix should be:

let projectConfigs: GraphQLProjectConfig[] =
        Object.values(config.getProjects() || {}) || [];

graphql/codemirror-graphql#129 diverged these libraries again - we should merge these two repos as soon as possible.

TODO before the release

• Complete test suites imported from codemirror-graphql and written for server/configuration/utils.
  • Improve test suites for the parser
• Command-line interface improvement to support locating .graphqlrc
• Better error Handling - find erroneous use cases that exits the server or sends a RPC message with 'error' type.

Nice-to-haves before/after the release

• caching unsaved/edited file contents in GraphQLCache.
• Custom validation rules
• pretty-printed CLI outputs

Also, I'm not sure where this one fits but https://code.visualstudio.com/blogs/2016/06/27/common-language-protocol summarizes the architecture for implemented GraphQL server interface pretty well as a superset. It's probably worth mentioning and finding a place to collaborate with this protocol.

Please feel free to add/edit the items above.

Seems like the recent refactoring to use Workspaces/Yarn/Lerna has broken the CI in a few different ways. For example, see #139 (about Flow errors).

Top-level yarn run testonly is dying locally and in CI with:

Error: Cannot find module 'graphql-language-service-utils'
    at Function.Module._resolveFilename (module.js:470:15)
    at Function.Module._load (module.js:418:25)
    at Module.require (module.js:498:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (/Users/glh/code/graphql-language-service/packages/interface/src/__tests__/getAutocompleteSuggestions-test.js:17:1)
    ...

And you can't run the tests in the sub-dirs as they all have stubs like this defined:

    "test": "echo 'Please run `npm test` from the root of the repo' && exit 1",

Top-level build* scripts are also busted, so I am removing them in #144 — we can replace them with something else that actually works.

Seems like we're flying pretty blind at the moment with respect to tests, Flow etc. cc @asiandrummer for visibility.

For deprecations, an appropriate style token should be generated and be included in the token contexts.

I suggest that graphql-language-service should prefer to use the online schema when an endpoint is specified in .graphqlconfig, and only on failure fall back to the schemaPath on disk.

This does leave open how a client might specify which endpoint to use when more than one is specified. Potentially this could be (optionally) specified in server Options. Edit: graphql-config by default will read process.env.GRAPHQL_CONFIG_ENDPOINT_NAME for the endpoint name so perhaps it is ok not to accept a name via config.

N.b. graphql-config has an endpoints extension for resolving online schemas.

According to .graphqlrc redesign proposal and my strongly feeling that multi-app is evil in this config file - I ask you to consider removing multi-app from graphql-language-service. Let try to implement your monorepo needs in some other way.

Current problems which I see now with graphql-language-service:

1. Problem with getConfigByFilePath, it may returns wrong config

Inspecting graphql-language-service I found that this code that may bring problems:

  getConfigByFilePath(filePath: Uri): ?GraphQLConfig {
    const name = this.getConfigNames().find(configName =>
      this.getConfig(configName).isFileInInputDirs(filePath),
    );
    return name ? this._configs[name] : null;
  }

It determines by filePath in input dirs app specific config and return it. So the problem may be if several apps will have the same file in input-dirs. You will get first config, but in reality may be needed another config.

2. CLI interface missing option

CLI may be pointed to multiapp config, so it should be somehow informed which config needs to take. In this case needed an additional option which will point to needed app name.

On the other hand, adding this option we complicate integration with IDE (it can not automatically choose the correct app, will need to provide some dialog window where a user chooses needed app). So as joke solution we may add one more dot-rc file.

So if we make restriction, that .graphqlrc contains only one app, all above problems disappears. Of course need to solve your monorepo problem. If you provide some real case, maybe we can find another solution together?

In npm, the current version of graphql-language-service-utils is 1.2.1 which seems to have issues when resolved transitively by the other older components.

Forcing graphql-language-service-utils to 1.2.0 resolves our build issue.

Normally all of the results for an npm-glob operation are files or directories that really exist. As a result, globResult.statCache contains a Map<string, Stat>. However, under some circumstances (TBD), some glob patterns, like those which are just simply a path to a file that does not exist, cause the statCache to have type like Map<string, Stat | bool>. Since bool obviously does not define an mtime property, this code blows up:

Object.keys(globResult.statCache).map(filePath => ({
  filePath,
  mtime: Math.trunc(
    globResult.statCache[filePath].mtime.getTime() / 1000,
  ),
  size: globResult.statCache[filePath].size,
}))

This issue was first reported here: stephen/vscode-graphql#17 (comment).

graphql 0.12.x is out and this repo requires 0.11.x (which is treated like a semver major difference)

If you use GraphiQL for example, this means duplicate versions of graphql are installed and warnings/errors occur.

This came up before in the last graphql update.

PRs:
#192
#193

If .graphqlconfig contains an includes key, with only a single glob such as below, the resulting set of matched files will always be empty.

{
  "includes": [ "{path/to}/**/*.{js, graphql}" ]
}

In the above example, glob would ultimately look for files ending in .js or .graphql which are literally in a directory called {path/to}.

This occurs because the underlying library performing the globbing (minimatch), does not expand glob braces when there's only a single value inside those braces. For instance, some implementations of glob (such as your shell) expand {foo} into foo. Minimatch does not perform an expansion in this case. It's unclear if this is by design or not.

When includes contains multiple glob paths, this behavior does not occur because, as one would expect, minimatch correctly expands {path/a,path/b}/**/*.{js, graphql} into ['path/a/**.{js, graphql}', 'path/a/**.{js, graphql}'].

The end result is that fragments are not cached when graphql-language-service first loads in the above case. Caching is thus delayed until each file has changed (a fact which is learned only after being notified by watchman or via language service protocol).

Any ideas when the graphql 0.13.* will be supported?

Hi @jimkyndemeyer and @martijnwalraven - I've been talking to you guys individually, but you guys have experiences/working examples of the IntelliJ plugin for GraphQL Language Service, which is amazing btw :D I just wanted to initiate the discussion for us to collaborate together in creating a IntelliJ plugin using this GraphQL Language Service and the server!

For the actual details to making it happen I have less preferences - I thought that we could either work together on already-existing @jimkyndemeyer's IntelliJ plugin and improve that, or start from the scratch depending on how the plugin development is structured and etc. You guys obviously have a better idea how this goes, but I'm here to help as much as I can.

Also, note that by us working together to implement this, we can make any changes we want in this graphql-language-service repo to fit your needs when this is still a private repo. Let me know how we can proceed!

This library is already pretty close to complying to the language server protocol from Microsoft. Since Nuclide/VSCode (which is that protocol) already has similarities between how they implement the language server, making graphql-language-service spec compliant to the language server protocol would be incredibly useful in supporting both IDEs.

According to the graphqlconfig spec, the string values contained within the includes value of .graphqlconfig (either top-level or project-level) are to be treated as file globs. However, graphql-language-service makes some incorrect assumptions about the structure of those globs (e.g. that they contain wildcards) and then replaces a portion of the glob with a hard-coded definition. Here's an example:

{
  "includes": [ "path/to/**/*.graphql" ]
}

"path/to/**/*.graphql" gets truncated at the first wildcard, then *.{js,graphql} is appended to produce:

"path/to/**/*.{js,graphql}"

While the set of .js and .graphql files isn't a bad set from which to extract queries and fragments, it's not actually what the user intended in this case (i.e. they intend to include JavaScript files).

I think the only reasonable expectation a user can have about how includes should behave is as defined by the spec.

Sample failure: https://travis-ci.org/graphql/graphql-language-service/builds/265282225

Repros locally too with a yarn run check (28 errors).

cc @asiandrummer for visibility

Enables IDEs to display field information on hover, much like GraphiQL does already.

getting 6 big scary yellow warnings all of this nature when trying to use the graphiql React component.. how do i silence this please?

WARNING in ./~/graphql-language-service-interface/dist/getOutline.js.flow
Module parse failed: ROUTE_TO_ABOVEMENTIONED_FILE Unexpected token (11:12)
You may need an appropriate loader to handle this file type.
|  */
|
| import type {
|   Outline,
|   TextToken,
 @ ./~/graphql-language-service-interface/dist ^.*$
 @ ./~/graphql-language-service-interface/dist/GraphQLLanguageService.js
 @ ./~/graphql-language-service-interface/dist/index.js
 @ ./~/codemirror-graphql/hint.js
 @ ./~/graphiql/dist/components/QueryEditor.js
 @ ./~/graphiql/dist/components/GraphiQL.js
 @ ./~/graphiql/dist/index.js
 @ ./client/components/graphql.js
 @ ./client/components/user-home.js
 @ ./client/components/index.js
 @ ./client/routes.js
 @ ./client/index.js

When this package is bundled with webpack, warnings are emitted ("Critical dependency: the request of a dependency is an expression") because of the dynamic requires here:

I encountered this when upgrading graphiql to 0.10.2, which depends on codemirror-graphql, which depends on this.

Scary warning on the last pull request that I looked at saying we need to re-"install" our Greenkeeper integration as it is going to stop working at the end of the month. I don't think we have admin privileges over the repo now though. cc @asiandrummer

🚨🔥⚠️ Action required: Switch to the new Greenkeeper now! 🚨🔥⚠️
This version of Greenkeper will be shutdown on May 31st.

Seen at: #114

This is a brain dump to get us started for discussing having the shared GraphQL configurations (at least the agreed common format of it). @schickling - please feel free to add anything that I've missed and/or misspoken of.

@schickling and I talked about an idea for a generalized configuration for GraphQL applications - since GraphQL-powered environments usually include information about the GraphQL artifacts (such as the location and specifications within the application directory), the idea is basically to define the information within one file, such as .graphqlrc.

What .graphqlrc currently supports, based on how this repository expects, is:

{
  "build-configs": [
    "app1": {
      "input-dirs": [
        "/dir/paths/to/your/graphql/files"
      ],
      "exclude-dirs": [
        "/dir/paths/to/ignore/"
      ],
      "schema-path": "/path/to/the/schema/"
    },
    "app2": { ... }
  ]
}

In above JSON, input-dirs and exclude-dirs are useful to determine where your GraphQL queries/fragments are defined if you have a complex directory structure. schema-path suggests where to look for a GraphQL schema definition, and it can parse .graphql or .json file.

After discussing with @schickling for a bit, a high-level proposal that came out was to suggest this shared GraphQL configuration idea as one of the best practices to develop GraphQL applications, and implement an example (or a reference implementation) for how one may set up the GraphQL configuration (one place suggested is an existing graphql-config repository). In addition to what the above JSON suggests, @schickling also had an idea to be able to customize the expected value for some of the configuration entries:

• schema-path can be a local path to the GraphQL schema definition within the application, or an URL to the endpoint that would be used to fetch GraphQL introspection:

"schema-path": {
  "endpoint": "https://localhost:8080/graphql",
  "localPath": "/local/dir/path" // This would be an optional fallback schema definition
}

This is not to require all GraphQL configurations to limit its potential to the above configuration options only - I can imagine some apps would like to define their own configuration options (i.e. Relay apps including Relay-related config options and such).

I'd love to hear what everyone thinks of this!