graphql / graphql-language-service Goto Github PK
View Code? Open in Web Editor NEWAn interface for building GraphQL language services for IDEs
An interface for building GraphQL language services for IDEs
Any ideas when the graphql 0.13.* will be supported?
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 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.
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).
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.
Enables IDEs to display field information on hover, much like GraphiQL does already.
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
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
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!
codemirror-graphql
and written for server/configuration/utils.
.graphqlrc
GraphQLCache
.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.
For deprecations, an appropriate style token should be generated and be included in the token contexts.
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!
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).
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.
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.
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() || {}) || [];
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
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.
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.
graphql-language-service
:getConfigByFilePath
, it may returns wrong configInspecting 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.
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?
graphql/codemirror-graphql#129 diverged these libraries again - we should merge these two repos as soon as possible.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.