Enable jupyter labextension build/watch to work for custom jupyterlab distributions

[jasongrout]

References

Code changes

Currently, jupyter labextension build/watch only work for building prebuilt extensions for core jupyterlab itself. For example, the federated example directly calls the npm builder itself, and cannot use jupyter labextension build because it is pointing to the wrong core package.json file.

This adds an option to jupyter labextension build/watch to give the core package directory. If a custom JupyterLab app follows the same conventions in its package.json metadata, you can prebuild extensions for it by pointing to its package directory with --core-path: jupyter labextension build --core-path=/my/custom/jlab/package /my/extension/to/build

I still left the example using the npm package builder by default to show how it can be done if you have access to the appropriate package.json.

User-facing changes

Backwards-incompatible changes

[jupyterlab-dev-mode]

Thanks for making a pull request to JupyterLab!

To try out this branch on binder, follow this link:

[blink1073]

Thanks!

[jtpio]

Nice, thanks!

Wondering what the best way would be for extension authors to target several distributions at once? For example both JupyterLab and JupyterLab Classic? For now they can use the default JupyterLab core path.

Should they produce two bundles / extensions, built with different -core-path?

[jasongrout]

Should they produce two bundles / extensions, built with different -core-path?

To be safest, yes, and they should install those two different bundles into different share directories, and the jupyter classic should load its extensions from this other directory by overloading the labextension_path.

The issue here is that core packages are not imported into a prebuilt extension, but if classic has a different set of core packages (in particular a more limited set), a plugin may not include a package that it needs.

And really, we still need to address different versions of jlab, which also count as different distributions.

[jtpio]

To be safest, yes, and they should install those two different bundles into different share directories, and the jupyter classic should load its extensions from this other directory by overloading the labextension_path.

Right, although it would be quite convenient to be able to load the same set of JupyterLab extensions automatically, without having extension authors to do extra work.

Otherwise, alternative distributions would probably have to document this in their extension developer guide, and mention how to make an extension compatible with JupyterLab and the other distribution (for example by documenting how to create two bundles and distribute them under share/labextensions/ and share/alternative_labextensions with data_files)

[jtpio]

you can prebuild extensions for it by pointing to its package directory with --core-path: jupyter labextension build --core-path=/my/custom/jlab/package /my/extension/to/build

Should we also add a command using the --core-path option to the usage tests, similar to this?

jupyterlab/scripts/ci_script.sh

Line 196 in 9170d39

jupyter labextension build extension --static-url /foo/

(just to cover the use of --core-path)

[jasongrout]

Should we also add a command using the --core-path option to the usage tests, similar to this?

Done!

[jasongrout]

@jtpio, @blink1073 - pinging for final review and/or merge. I think I've addressed everything asked for.

[jtpio]

Thanks!

[jtpio]

@meeseeksdev please backport to 3.0.x

[jasongrout]

Thanks!