We discussed this in a meeting, and realized that it's more subtle, since you'd want to use yarn link to install the dev core packages into the federated extension. Essentially, since the core extensions are all in a monorepo, yarn automatically links them all together so they see the version that is on disk, but since a federated extension would be in a different repo, we'd need to do that linking ourself.
That said, we could have a federated extension compiled against a released set of core packages, but then loaded in dev-mode with the dev packages. For many situations, this would work (even if it complains if the dev mode versions do not match the existing released versions).
This is a much easier way to develop extensions against a development install of JupyterLab than the current add:sibling approach. While it may not work all the time, I think it will be helpful sufficiently often that we should make it possible.
For now, the dynamic?federated extensions are forced-disabled in dev_mode
Lines 618 to 619 in f7cb7b5
Sometimes, like the work done in #8804, we need those extensions enabled in dev mode
Add a setting/flag like
--extensions-dev-modeto keep the extensions enable in dev mode,.
The text was updated successfully, but these errors were encountered: