Add lsp-ws-connection to repo

[bollwyvl]

References

• Reorganize client source with lerna and typescript projects #76 (step 3)
  • turns out we kind of need this before step 2

Code changes

• brings lsp-ws-connection into the repo
• ts, tslint, yarn, etc.
• also using chai instead of expect because OH MY GOD SOME DAYS I CAN'T STAND JS STUFF AT ALL
  • but seriously, it didn't seem to work properly with ts3.7
• moves initializeParams into an overloadable protected function
  • not for any good reason, yet, but it was the first thing i wanted to do

User-facing changes

None

Backwards-incompatible changes

None yet. In a follow on, I'll probably be taking a harder look at a) whether we need it at all (MessageConnection seems just fine) and b) how we might make it more configurable by some means other than subclassing and of course c) entirely removing its knowledge of a documentUri, because we only need one websocket per language server.

Chores

• linted
• tested
• documented
• changelog entry

[jupyterlab-dev-mode]

Thanks for making a pull request to JupyterLab!

To try out this branch on binder, follow this link:

[bollwyvl]

might be able to clean these up, now that they are no longer fighting...

[bollwyvl]

still didn't look at these yet...

[bollwyvl]

the one thing i actually changed

[bollwyvl]

well, some of these, too...

[bollwyvl]

Hopefully have fixed the version detection stuff which was failing on windows. Still need to figure out why i'm having issues with menu selection, but haven't gotten my windows vm back up and running yet.

[krassowski]

I guess we should not stop at the fork mention, but also add "Copyright (c) 2018, William Conlon, ISC" in here.

Legalities aside I would like to credit @wylieconlon as it would not be possible to start this project without the leading work of @wylieconlon (and obviously lots of code in this PR is @wylieconlon code with slight modifications). @wylieconlon would you like any specific backlinks or mentions? Are you ok with the current mentions?

[bollwyvl]

Sure, happy to give credit where due!

I think we may end up moving further and further from what remains of the code from upstream: for example, using tsee would let us keep the full event typing information, and remove the conflicts we're seeing between @types/node and @types/event. Or, as mentioned, just use MessageConnection more directly.

Of course, because we don't control the end-user jupyterlab webpack.config.js, we'll need to keep webpacking the part that interacts with fs, so this package (and its special needs) will continue to exist.

[bollwyvl]

Huzzah, looks like all the CI passed, provided it can actually upload the final report bundle!

[krassowski]

c) entirely removing its knowledge of a documentUri, because we only need one websocket per language server.

before that we would want to have multi-document tests; I saw a regression with inspections being displayed in a wrong file...

Otherwise, ready to merge?

[bollwyvl]

Yeah, if we're good on license stuff. Still trying to unwind all the stuff I did on the heirarchical symbol branch... This is the first step, once we have it in place for hacking, we can start the process of moving the ownership of an lspwsconnection to a manager singleton. That might also be the right time to give up trying to guess language names, and just go to implementation-keyed sockets. Or something. We will likely end up wanting a pattern not dissimilar to how @jupyterlab/services hands out sessions for kernels and terminals. we'd likely further abstract the connection. At any rate, it'll be good to have the windows tests working!

…

On Mon, Dec 9, 2019, 16:37 Michał Krassowski ***@***.***> wrote: c) entirely removing its knowledge of a documentUri, because we only need one websocket per language server. before that we would want to have multi-document tests; I saw a regression with inspections being displayed in a wrong file... Otherwise, ready to merge? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/krassowski/jupyterlab-lsp/pull/107?email_source=notifications&email_token=AAALCRHOG2QMKFR27QVXLQTQX2275A5CNFSM4JXRZZCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGKZKMQ#issuecomment-563451186>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAALCRDTZ7BUKXTGZQL44ODQX2275ANCNFSM4JXRZZCA> .

[krassowski]

Can we synchronize the lsp-ws-connection versions between jupyterlab-lsp/package.json and metapackage/package.json? or should we have it in the former in the first place?

I stuck trying to modify lsp-ws-connection` but the changes are not reflected since it is usinga an old version.

[krassowski]

I really like the idea of the monorepo (it improves workflow greatly), but I got lost with the complexity of the building/watch system and can't figure out how to get the changes in lsp-ws-connection to be reflected in mu builds... Maybe I need to rm -rf everything and install from scratch, but if there is any secret knowledge I am missing, please do help @bollwyvl.

[bollwyvl]

Hm, just what I updated in contributing... Though clearing out your built lab will be required the first time after the merge. But yes, bumping the version would also be a good idea, too. I think that's one thing I didn't bring over from the symbol tree branch.

…

On Mon, Dec 9, 2019, 18:38 Michał Krassowski ***@***.***> wrote: I really like the idea of the monorepo (it improves workflow greatly), but I got lost with the complexity of the building/watch system and can't figure out how to get the changes in lsp-ws-connection to be reflected in mu builds... Maybe I need to rm -rf everything and install from scratch, but if there is any secret knowledge I am missing, please do help @bollwyvl <https://github.com/bollwyvl>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/krassowski/jupyterlab-lsp/pull/107?email_source=notifications&email_token=AAALCRGJ6TUJAQQCBSQORL3QX3JIZA5CNFSM4JXRZZCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGLC6FA#issuecomment-563490580>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAALCRC4GDEGE5U552UDGTTQX3JIZANCNFSM4JXRZZCA> .

[wylieconlon]

I'm glad you found the project useful! I haven't really done a full review of your usage, but the license allows forking/vendoring like you've done. Were there any bugs you encountered or other issues that could make their way back into the main repo?

[krassowski]

Thank you, @wylieconlon! No, not many issues significant enough to contribute back yet, but there is a thing that I am looking into right now, related to sending messages before initialization has been completed by the server (according to the specification client cannot send any messages before that; there is a check but it is on being connected, not being initialized). Again, this is a minor thing but maybe changing:

    if (!this.isConnected) {
      return;
    }

to

    if (!this.isConnected || !this.isInitialized) {
      return;
    }

in a few places would bring the behaviour closer to the LSP specification. Also, having didClose would be nice (but I am not sure if this is relevant to the upstream project).

Also, I am experimenting on sending partial text updates and other extensions (rather than bugfixes). The ability to flexibly extend (and move away from node-based and callback-based constructs) was the primary reason to fork.