Setup way too complex

[matthewoates]

Isn't it sufficient to only point to the schema.graphql file? Also, can't it make some assumptions about where that file might be?

[kumarharsh]

Thank you for the suggestions. I myself have not worked with a lot of graphql projects, and it seems to me different teams organize their schemas differently. For the projects I'm working on, the schema is too big to be contained in one file, and before making the plugin, I'd seen more projects which followed similar trends of splitting up schema, but their folder structure was different enough, so baking in default seemed more work than necessary. That being said, I appreciate your concern, but would like more discussion around this to see how other developers prefer to organize their projects. I'll keep this issue open for discussion.

[batjko]

I have a fairly large schema at work, which we split into conceptually segregated js files (usually one file for each type and all its resolvers), and use the merge-graphql-schemas package to merge the types and resolvers from the various files. I think for any large schema it makes sense to modularize somehow, so I appreciate that some config will often be required to tell this extension about it.

However, the fact that one needs this @playlyfe/gql library and then also watchman (which is a PITA trying to set it up on anything else but Macs), in addition to the configuration file, just in order to get the basics of this extension running, does strike me as quite an overhead.

Watchman should certainly not be necessary. Linters and others just spawn a background 'server' process to watch files, completely transparent to the user.

[matthewoates]

Great discussion so far. The schema.graphql file that I'm mentioning is a compiled asset that combines all types for your GraphQL schema into one file. I agree that any non-trivial GraphQL service should have its source code for all of its types split up into different files.

Here's what I've been using to create the single GraphQL file: https://github.com/relayjs/relay-examples/blob/72e0644c572ef4a5f74d113fc75bc8a27030edd3/todo/scripts/updateSchema.js

It's not very user friendly, but it works.

EDIT: this looks similar to the merge-graphql-schemas lib @batjko mentioned.

[kumarharsh]

@matthewoates the plugin automatically combines the graphql schema so you don't have to.

Yes, I take your point about watchman - it really is a PITA. I work on Windows, and facebook's tooling is not at all productive on windows - watchman is still ok, but getting flow running and keeping it running on my machine has been impossible for me. It'd be helpful if an issue can be opened on gql regarding a move to something better than watchman.

[batjko]

@kumarharsh Done (https://github.com/Mayank1791989/gql/issues/62). Although I have not suggested a particular replacement (not sure myself) at this point, it would at least get the thought on the radar.

[the-simian]

The fact that one must install watchman globally to make this plugin work is a major code smell. If the project implements watchman, is there not a way to encapsulate that in the plugin?

same with @playlyfe/gql , is it not possible to make this be a dependency of the plugin?

[kumarharsh]

Agreed @the-simian. As per https://github.com/Mayank1791989/gql/issues/62#issuecomment-330945526, I think the reliance of watchman itself might be removed. I'll keep this topic updated.

[alloy]

Nice! The watchman requirement being removed from gql is one step forwards, but, like @the-simian, I also wonder if the dependency on gql can’t be done as part of this extension rather than requiring the user to add it to their dependencies?

[pyrossh]

Schema files don't necessarily need to present in the file system it should also be able to be queried from the server. That way we don't need to generate a single gql file when we are stitching schemas using graphql-tools or using apollo. This project solves it well albeit only for typescript though since the compiler is powerful. https://github.com/Quramy/ts-graphql-plugin They allow a path or a url,

schema": "path-or-url-to-your-schema.json"

It also seems like a simple flow. This will a real booster for apollo based projects which is gaining a lot of traction these days.

[malexandre]

I agree with other that the gql dependency should be included inside the plugin. It's weird that I need to install a module in my project for an extension that my coworkers won't use because they are not all on VS Code. Also, I think the .gqlconfig file's option should be options of the extension (options means it can be defined globally, per workspace, per user, etc.), for the same reason. Again, I do not see why I should create a file in the project for my editor. The project files are for the team.

At least that's my point of view. That's still awesome to have an extension for graphql intellisense.

[felixfbecker]

My proposal would be:

• Replace watchman with chokidar
• Like all lint extensions (e.g. eslint), if gql is installed locally or the path is configured, use that, otherwise use the bundled version.

This should work out of the box if possible (0 config). Currently there are too many things that could cause a configuration to not work, which makes it really hard to ensure everyone on a team has a working setup.

[kumarharsh]

Thanks for the inputs.

Most of the work for this is done - we'll be releasing a new version soon-ish.

1. watchman will be optional and configurable, with an option to use a nodejs based watcher (details are being sorted out) 1a. I would also point out that preliminary usage shows that watchman is more efficient than the node-based watchers - especially for larger projects. Will give an update with more concrete numbers.
2. If the gql library is not found, it'll be automatically downloaded by the plugin
3. Better support for more usecases is incoming.

I'll keep you all posted on further development.

[Trellian]

@Mayank1791989 Sorry to be the one that asks, but... do you have an ETA on the arrival of v3.0?

[bmayen]

Watchman also seems to be a blocker for setups on WSL. VSCode is running on Windows but node_modules is installed under WSL. In this case I'm getting "Watchman was not found in PATH" and server closes.

Any workaround for this in the meantime?

[kumarharsh]

You can install watchman too under WSL .

[bmayen]

yep, I have it installed under WSL, but there seems to be an issue with VSCode running on Windows while watchman is under WSL.

[felixfbecker]

@kumarharsh are there any blockers left for releasing a new version we can help with?

[kumarharsh]

@felixfbecker I'm out of town so haven't worked on integrating the v3 branch of gql with this. Once I'm back, I'll work on the release

[chrismwendt]

Any update on this?

[kumarharsh]

Its mostly done - one issue with the automated setup that we explored was to use a node-based watched for people who don't want to use watchman. But during the course of development, we found that there no no watched which provides bullet-proof watching capabilities cross-platform - even VSCode is using three different watchers(!) we just need to sort some stuff around that.

[felixfbecker]

@kumarharsh what is the problem with chokidar? It is used by many popular cross-platform tools, e.g. Gulp

[kumarharsh]

There are a bunch of problems. See https://github.com/Axosoft/nsfw/issues/18#issuecomment-329249203 for some of them (actually, that whole issue is very insightful).

[felixfbecker]

@kumarharsh despite that, many tools work just fine with chokidar. How about using watchman when it is available and falling back to chokidar?

[Akumzy]

I'll be happy to help with fs-watcher

[RicCu]

Hi, what's the status on this?

[kumarharsh]

No updates.

[dosstx]

Hi, just an update that I am unable to get this working in Windows due to watchman screwing up my paths.