default to client watcher pattern ala LSP

[acao]

We have a nice custom watcher built into our server using fb-watchman, however vscode and other LSP oriented IDE clients would expect to be able to provide their own, and for this server to respond to workspace watch/file change notifications sent from the IDE client.

Thus, we need to decouple this watcher from the server such that it doesn't bring many additional dependencies, and the fb-watchman dependency itself would become an optionalDependencies entry that we can suggest to the user if they are working with an IDE that expects a server watcher, and they aren't using an LSP client compatibility layer with a built-in watcher for their IDE (which is probably common). Using a server side watcher is possible, but is against the reccomendation of the microsoft LSP docs.

We could also ship it as an additional wrapper package, of the server bundled with fb-watchman. no harm in adding more packages to the monorepo. It could also move to a contrib space

[acao]

@zth do you want to weigh in here as well? it seems that LSP reccomends against server side watchers, so we can move that logic to a vscode client lib of some kind that you would use in your extension.ts to assign watchers and parse.

[zth]

I think this approach sounds good! I actually think it'll be fine to just remove watchman/the server side watcher entirely, and then wait for the need for a server side watcher to actually arise before building one. What do you think about that?

[acao]

@zth thats what i'm hoping for, yeah! we can just reccomend that they use an lsp-oriented client implementation, like vim-lsp, emacs-lsp, sublime-lsp, etc. if we need to revive the watcher by popular demand we can in a contrib space

[acao]

https://github.com/sublimelsp/LSP i actually really want to create an example extension with this, it looks very mature and would be a great example. as for the multi language regex parser, i think we could export that as a shared module to use for this interface https://code.visualstudio.com/api/references/vscode-api#2532