Refactor client

[mbana]

Refactoring the client a bit

• moving classes to separate files.
• created classes for the Converters.

We're also doing a WebSocketReader. If my employer is happy to push the changes back, I'll create a PR for that as well. That said, the client lib will be structured differently though so as to only allow the importer to choose a specific set of transports required.

Many thanks,

[msftclas]

Hi @mbana, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!

The agreement was validated by Microsoft and real humans are currently evaluating your PR.

TTYL, MSBOT;

[msftclas]

Hi @mbana, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!

The agreement was validated by Microsoft and real humans are currently evaluating your PR.

TTYL, MSBOT;

[akosyakov]

@mbana Is it about Monaco integration: #88? How does it help? I see that converters still depend on vscode types: https://github.com/Microsoft/vscode-languageserver-node/pull/118/files#diff-e05feeb2a7817f9fe64dd047e2c12b00R1.

Is not having WebSocketReader and WebSocketWriter enough to change transport? Why not?

[dbaeumer]

@mbana I agree with @akosyakov: why does this help and what is the improvement. The client already exports both converters as properties.

[mbana]

i was trying to understand the structure of the various projects and along the way i started to move classes etc. to separate files. i guess it saves time by having most of the implementation in one file?

vscode-languageserver-types: not sure i understand. why is this an issue? the package seems mostly interfaces... please explain.

[dbaeumer]

@mbana What do you mean by

vscode-languageserver-types: not sure i understand. why is this an issue? the package seems mostly interfaces... please explain.

[mbana]

i wasn't sure what @akosyakov meant.

that said, why this an issue? vscode-languageserver-types doesn't include vscode so that's fine. it's only vscode-languageclient that does which is understandable - it marshalls to and fo a LSP. couldn't every LSP client need to do this?