Migrate to JupyterLab 2.0

[krassowski]

We will need to branch off at some time in order to migrate to JupyterLab 2.0 (which will be released soon). It would be good to merge any existing PRs (other than my stale ones) and avoid starting any new substantial work (other than bugfixes), particularly anything touching the JupyterLab internals. Also, the icons system is updated in 2.0 - that's why I did not add a nicer icon so far.

There is a draft migration guide here: https://jupyterlab.readthedocs.io/en/latest/developer/extension_migration.html. If we have time to do this early, we can contribute to making it more complete.

I might have some time this weekend but will rather spend it writing more browser tests so we can have a well-tested transition. @bollwyvl please let me know if you have any other local work related to browser tests that I should wait for.

[bollwyvl]

Good times. A test I wanted to add for the "one socket" pr was to open ten+ files with the same language... The existing event thing has a hard maximum listener count. Master doesn't have this problem, as it would just keep opening websockets, and won't fall over until you run out of RAM (or sockets, which can happen). To fix it, I'd have to remove the remaining per-doc .on() calls, which might motivate the diagnostics refactor. One thing I was mulling over, since we want to get into core: what if we started the 2.0 integration work directly against a fork of jlab? Now would be a swell time to start following the development pattern _exactly_ of what lab is doing (even if we keep doing additional real-browser tests, which I prefer to the puppeteer ones lab has, but that's another story). I'm pretty slammed at work, but I'll see what I can do.

…

On Wed, Jan 29, 2020, 14:18 Michał Krassowski ***@***.***> wrote: We will need to branch off at some time in order to migrate to JupyterLab 2.0 (which will be released soon). It would be good to merge any existing PRs (other than my stale ones) and avoid starting any new substantial work (other than bugfixes), particularly anything touching the JupyterLab internals. Also, the icons system is updated in 2.0 - that's why I did not add a nicer icon so far. There is a draft migration guide here: https://jupyterlab.readthedocs.io/en/latest/developer/extension_migration.html. If we have time to do this early, we can contribute to making it more complete. I might have some time this weekend but will rather spend it writing more browser tests so we can have a well-tested transition. @bollwyvl <https://github.com/bollwyvl> please let me know if you have any other local work related to browser tests that I should wait for. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/krassowski/jupyterlab-lsp/issues/186?email_source=notifications&email_token=AAALCRG55TWKZAITWOE4YI3RAHI7TA5CNFSM4KNKB7KKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IJUDJSA>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAALCRASNX5OFW3MUNE7MH3RAHI7TANCNFSM4KNKB7KA> .

[bollwyvl]

The day has come 🎉 !

https://pypi.org/project/jupyterlab/2.0.0/

How do you see this playing out? It might be nice to get #202 in and cut 0.8.0 releases as the final thing for the 1.2.x line, and then concentrate on getting going here. Seems likely the jumper extension will need upgrading: time to move that into this repo?

[krassowski]

We could move it here, but aiming to split it into "jumper-core" and language-specific implementations (don't have to be now, I can do it later!)... just to say it out loud, the UX will might suffer with this move if it would mean that the jumper is no longer installable separately, without lsp - if someone is used to having the jumper without installation of the server extension and a language server, this may be a step back for them. So it would be ideal if it was still possible to install it separately, but even if it is not possible, we may want to roll with the 2.0 being a big breaking release.

[krassowski]

I have small uncommitted (and unfinished) work on foreign extractors that I want to merge into 0.8, but if you have time to work on 2.0 port, I could backport it later as well. After 0.8 release I will create a 0.8.x branch and let's carry on on master. Just one litter comment on #202 (sorry for the delay here) something with a docstring seems odd.

[bollwyvl]

jumper without installation of the server extension and a language server

I'm all for having it remain standalone, separately installable: I'm just suggesting that having its development in this repo (especially if you're thinking about splitting features) would help during the 2.0 transition (otherwise we're blocked here entirely), and future features, a la multiple possible targets, might be easier to co-develop.

I'll have a look at #202: and never worry about keeping me hanging! as long as we're moving forward, whatever the pace, I'm happy.

[bollwyvl]

Made those fixes in #202: i'll watch CI, and if everything seems on the up-and-up, i'll start wading into lab 2.0 as a fork off of that.

in the meantime, some field notes from migrating another extension: aside from the painless phosphor -> lumino, I hit:

• icons: it has lots of dynamic icons, this was a pain
  • it's possible to do the react-snowstorm-of-death really hard if your svg is malformed in any way
    • that's probably a good thing... unless you're letting users dynamically make icons
• the signature changed on VDomRenderer (it always needs a model, now)
  • but that's a good thing
• dom changes: a few things lost selectors for testability, like command toolbar buttons :P

some things i want to do over there, that we'll probably want over here:

• it's possible to disable the node build check now
  • this will help during robot tests, and we should land it ASAP
  • but it does increase the chances that you test against a dirty build
• running: would love to get some things into the running sidebar and stoppable there
  • this will help us, but doesn't have to be on the first PR

[bollwyvl]

CI good over on #202!

[bollwyvl]

disable the node build check now

this looks great on test logs: far less noise

get some things into the running sidebar and stoppable there

this worked pretty well, but I have far little observability about the incidental background task i'm starting, and have to press the refresh button. however, i think for language servers, it will be great. clicking on a language server can pop open whatever we want: it will feel good to have per-server config show up there, and be great to be able to stop servers without reloading the browser/notebook server or mucking about with kill.