Do we need .yarnrc, or can we always build the extension with jupyterlab 4 that doesn't need it?

[consideRatio]

I understand that we have .yarnrc to enable jupyterlab <4 to build the jupyterlab extension, and .yarnrc.yml to enable jupyterlab>=4 to build the jupyterlab extension.

But since we seem to have a pyproject.toml that declares build env stuff, would it be sufficient for us to update this part to require jupyterlab 4 in there and build the extension with jupyterlab 4 also for jupyterlab 3?

https://github.com/jupyterhub/jupyter-server-proxy/blob/7360d846f1786db4419bac7df3671cb72acb0ba8/pyproject.toml#L1-L12

[manics]

Alternatively can we drop Jupyterlab 3? It's nice to support old versions, but is it worth the added maintenance burden? The core functions of jupyter-server-proxy have been pretty stable for a while.

[bollwyvl]

drop Jupyterlab 3

I can't recommend this route. There will be a lot of deployments that don't upgrade immediately.

For this extension, it should be possible to ship an extension, built only with lab 4, but will run in 3 and 4, and as this repo already has extensive, real browser tests, it would be safe to do so even if a few as anys are needed to appease typescript.

require jupyterlab 4

Yes, having a single build environment (with a stable SHA) is by far the simplest play: the two epochal versions of yarn can't share lockfiles or config, so there's really no supporting both without a lot of jumping jacks.

This is also good from a CI perspective, as testing against the as-installed

Even in the yarn that ships with lab 4, there is some config worth doing: here's what i've been moving towards:

#.yarnc.yml
enableInlineBuilds: false
enableTelemetry: false
httpTimeout: 60000
nodeLinker: node-modules
npmRegistryServer: https://registry.npmjs.org/
installStatePath: ./build/.cache/yarn/install-state.gz
cacheFolder: ./build/.cache/yarn/cache
logFilters:
  - code: YN0006
    level: discard
  - code: YN0002
    level: discard
  - code: YN0007
    level: discard
  - code: YN0013
    level: discard
  - code: YN0019
    level: discard
  - code: YN0008
    level: discard

This cleans up a lot log of noise, and helps ensure a more reproducible node_modules folder.

[consideRatio]

I see significant value in supporting using the labextension in jupyterlab 3 environments as well as jupyterlab 4 environments a while longer, but I don't overview the complexity of supporting it well.

But when it comes to how we build the extension, which is packaged as part of wheels for use in jlab 3-4, I figure it can make sense to always build the jupyterlab extension in jupyterlab 4 environments - and maybe we already do.