Let developers override or disable a command in a different extension

[JasonWeill]

Problem

While investigating possible solutions for jupyterlab/jupyter-collaboration#364, I was considering disabling the docmanager:save command in JupyterLab when a user has installed and activated the jupyter-collaboration extension. However, it doesn't seem like this is supported. I found a Discourse thread from 2020–2021 in which @lodka (not necessarily the same user on Discourse as on GitHub) shared an idea that technically worked, but, as @jasongrout confirmed, was not recommended and not expected to be durable.

Proposed Solution

Allow extensions to override or disable commands in other extensions, such as by replacing a command with a no-op.

Additional context

This introduces a risk that a malicious actor could override an innocuous command to do something harmful, such as by injecting code that leaks data to an untrusted third party. Extensions that override built-in commands might require additional confirmation upon installation.

[jasongrout]

IIRC, the way we addressed this basic issue in the menu system, where we wanted some generic command that could have alternative implementations depending on the context (like the current document), was to make a top-level command that would delegate the work out to other extensions. So the base command essentially was making itself extensible. What do you think about making the save command extensible, rather than making an override mechanism?

[JasonWeill]

Making the save command extensible would allow us to implement jupyterlab/jupyter-collaboration#364 without creating a new command for use with RTC. There is still the risk that an extension, including a safe-looking extension, might modify the save command to do something harmful with user data. Should we warn users, at least once after extension install, that the save functionality has been modified by an extension? I want to provide safety without causing alarm here.