Rename jupyterlab extension id to match convention

[cmd-ntrf]

Allow disabling the extension using the name reported for the plugin by jupyter labextension CLI tools.

More details in issue #322

[consideRatio]

Important, this was considered a breaking change:

The name should probably follow the upstream pattern, e.g. @jupyterlab/server-proxy:plugin, but shouldn't be changed until a major version bump of this package (e.g 4.0.0).

[consideRatio]

Should this be named @jupyterlab/server-proxy to match the legacy npm package name though, or should it be named something more coupled to its current name - jupyter-server-proxy - the PyPI package? The current name jupyterlab-server-proxy doesn't seem right in any way though.

[yuvipanda]

I always imagine that extensions under the @jupyterlab/ extension naming are in the jupyterlab org, rather than the jupyterhub org.

[consideRatio]

This repo has a npm package in the jupyterlab org, but we dont need it for jupyterlab 3+ so should we reference it here now?

I think we want to reference a name including the repo name/pypi name and maybe also jupyterhub/ - but not the old npm package unless its really to point to some npm package - in whatever format is common.

[bollwyvl]

This repo has a npm package in the jupyterlab org, but we dont need it for

jupyterlab 3+ so should we reference it here now?

Yes, by convention it should keep publishing under an npm name, ideally the same one. What org it is under isn't very important, but having it be _something_ consistent is important for downstream packages.

[consideRatio]

Hey, triaging open PRs and marking this as a draft.

I figure that unless we can name this @jupyterhub/jupyter-server-proxy that seems proper, we shouldn't make a breaking change about this.

If we can do that depends on getting control of the npm organization first and we are awaiting a claim to take control of an existing jupyterhub organization now in jupyterhub/team-compass#562 (comment).

[consideRatio]

We have control of the jupyterhub organization, @minrk @manics @yuvipanda what do you think - should we go for it?

I like the idea of decoupling this from being under @jupyterlab and named inconsistently like server-proxy instead of jupyter-server-proxy as the repo and python package is named.

Is it okay if I move towards resolving this by defining a NPM package / setting up credentials etc for the CI system to push to @jupyterhub/jupyter-server-proxy going onwards?

[consideRatio]

Closing in favor of #363. We need to make more significant changes than just the one-liner. If there is agreement in this linked github issue, I'll go for it.