Problem

Having two ways to refer to extensions can be confusing to users and extension authors.

It also requires writing documentation (and keeping it up-to-date) about the differences:

• Managing Extension: https://jupyterlab.readthedocs.io/en/stable/user/extensions.html#managing-extensions-with-jupyter-labextension
• https://jupyterlab.readthedocs.io/en/stable/extension/extension_dev.html#source-extensions
• https://jupyterlab.readthedocs.io/en/stable/extension/extension_dev.html#prebuilt-extensions

It also holds complexity within the JupyterLab code base.

Proposed Solution

We drop support for managing source extensions with jupyter labextension:

Pros:

• Remove the extension manager, or update it to make it work with prebuilt extensions only -> less confusing to the end user who might not know the difference between the two types
• Remove quite a bit of code from the lab code base (install, update, uninstall commands) -> better maintenance
• Easier to reason about how extensions work in JupyterLab
• Focus efforts on a single way to provide extensions to JupyterLab. We can then build more focused tools for extension authors wanting to quickly hack around (a la classic notebook, also related Getting Started Docs for Non-Developers #11075), without worrying about breaking the second way of installing extensions with jupyter labextension install
• Maybe a good opportunity to streamline the bootstrap.js / index.js boilerplate and make it easier to reuse in other lab-based apps like retrolab, jupyterlite, voila, quetz-frontend
• Most of the other JupyterLab distributions reusing JupyterLab extensions do not support managing source extensions with jupyter labextension install / update /uninstall. They only load prebuilt extensions at startup:
  • JupyterLab Desktop
  • RetroLab
  • JupyterLite
  • Voila (soon to be a lab-based app)

Cons:

• in some cases it can be useful to be able bundle everything together. Dropping support for source extensions would also drop support for this

Additional context

This came up during casual discussions. Also something we have been thinking about over in JupyterLite. Trying to imagine what it would look like if everything was a federated extension, even the core plugins.

Also many third-party extensions have now been updated to be prebuilt extensions since it's a much better experience for the end user. There should now be a lot less users installing extensions with jupyter labextension install.

Opening this issue now to check whether this is something we would like to consider for 4.0.

It was also something briefly considered for 3.0, but since the prebuilt extension system was still new at the time it was better to keep both system for the 3.0 release.