FEATURE: Remove dependency "watchman"

[DanielHabenicht]

Actual Behavior

Users who want to use this extension have to install watchman. This is more time-consuming than just clicking install in VSCode. (especially for Windows Users)

Expected Behavior

The VSCode extension should be a one-click install.

Steps to Reproduce the Problem Or Description

Install it on your system.

Specifications

• GraphQL for VSCode Extension Version: Preview [Unreleased]
• VSCode Version: 1.35.1
• OS Name: Windows
• OS Version: 10

Logs Of TS Server || GraphQL Language Service

should not be needed

[DanielHabenicht]

I don't know a thing about typescript extensions, but other node based tools are using Chokidar

[Bdthomson]

+1

[lostfictions]

For reference, here's the process a user has to go through to get this extension working:

Go to the Watchman website

Hmm, looks like all the installs are beta. And my operating system isn't supported. Let's give it a shot anyway.

Okay. Let's comb the Watchman issues, I guess?

Ah, I guess I have to be a logged-in Github user, or my journey as a potential user of this extension ends here. I also note with bemusement there's an issue called "Binaries seem broken on linux" which bodes well for me. But at least I know where to get the binaries!

I... guess I'll just download a random build off master that passed CI? Maybe?

So... okay. I need to put this 175mb binary on my PATH? Sounds legit.

Gotta remember to mark the executable bit.

Well, I guess it doesn't work after all. That's that!

I'm genuinely curious how many users actually use this extension for anything more than syntax highlighting, since Watchman really doesn't seem to want people to use it!

[info-house-by]

doesn't work for me on Windows 10. I installed watchman for react-native projects. But it doesn't work here anyway.

Getting errors: Unable to open 'schema.graphql': Unable to read file '\d:\app\schema.graphql' (Unknown (FileSystemError): Error: UNKNOWN: unknown error, stat '\d:\app\schema.graphql').

[skurgansky-sugarcrm]

https://github.com/graphql/graphiql/tree/master/packages/graphql-language-service#dependencies Watchman is dropped as dependency.

[acao]

so, late last year we released graphql-language-service-server@2.4.0 which removes this dependency, in order to better adhere to the LSP architecture where the client is who watches for files and messages them to the LSP server. I actually did the typescript conversion and then developed these releases of graphql-language-service-server (i'll just call it gls-server for now) using a linked forked copy of this extension! So i'm pretty confident in how it all is looking. I wish we'd introduced a PR for these changes last year, but @divyenduz had some issues with my first attempt and had to revert.

as an explanation of why gls-server ever had a watchman dependency, it was originally built before vscode was very popular at all, for when Atom, sublime, etc and consumed via the graphql-language-service CLI (which has been renamed to the more apt graphql-language-service-cli) which can be controlled via node or python or lua or java or coffescript or whatever language that particular editor supports for extensions. now that vscode probably makes up 55% of editor usage based on a stack overflow survey

TLDR; Now that Prisma has granted me maintainer rights to this repo as of last week, and I can help @divyenduz accelerate this work, I have PR #184 in the works over here now that introduces the upgrade to gls-server as well as many other required changes for new features.

The most glaring regression from removing watchman support is that declarations are only built as the files are opened as tabs in vscode. what this means is that you can't open a tsx file with a query and peek definition on fragments, input types, etc right away - you will have to actually open the schema and query files in your editor to cache the definitions. you may have noticed a similar regression in vscode a year or so ago with typescript definitions. the resolution for this is that the language server just has a few more workspace-level events it needs to respond to, such as WorkspaceSymbol, and hopefully we can use the most LSP/vscode-api appropriate solution for pre-loading all files and definitions in a workspace.

Is it ok that we experience this regression for the first pass at dropping watchman, or is it worth a longer wait to resolve that?

[acao]

would anyone want to test a pre-release for this, despite the regression? and let me know if you experience a performance boost?

[DanielHabenicht]

I think I would rather wait, as opening all .tsx files can be more time consuming than installing Watchman especially for big projects as it is also repeated work each time you open vscode. (it is a "time-consuming steps to install Watchman" Vs "opening definitions EVERY TIME")

But I am also not using this extension anymore, since I don't work with graphql anymore :/ - so it up to you.

[lostfictions]

@acao thanks so much for your work on this! for my part i'm not currently working on a gql-based project so wouldn't be able to provide feedback on a pre-release now, but it seems like a good idea! it'll definitely be appreciated as soon as i'm back working on codebases with gql :)

that said, re: your previous comment, i'm not sure about cutting a regular release with a functionality regression -- it seems like that would disrupt current users a fair bit, so it might be better to keep it as a pre-release until there's functionality parity?

[acao]

0.3.1 released! please open new tickets if you have any issues