Using token names strings vs importing tokens

[jasongrout]

We use several internal JLab/Lumino APIs in this extension. One use is this:

https://github.com/wolfv/jupyterlab-dynext/blob/cf8e71b0f985be2be767aa2c56eb7cb7dacc1aa8/src/index.ts#L15-L17

This makes it possible for the user to give the required/optional dependencies of a plugin as token name strings rather than importing and using a token. We do this because we didn't build the infrastructure to support importing things, especially since raw static import statements are not allowed in function bodies, which is how we are evaluating the user code. We thought giving token names as strings was a nice balance between being very simple to specify, mapping pretty closely to what would be done in a full-blown extension, and making sure we could support what was currently loaded in the DI container.

If we wanted to support import statements to get tokens, we could explore making a webpack import function available in the environment, and rewriting the static import statements into the equivalent webpack import statement in the actual evaluated code. A bonus of writing this would be that a plugin might be able to import from other js dependencies available in the existing frontend webpack cache besides other plugins in the dependency injection framework. Also perhaps there would be a way of loading modules from a webpack bundle, similar to how our example loads bqplot from an AMD module.

Another thought is that perhaps Lumino could support giving the plugin requires and optional dependencies as strings. I would recommend against this, as it gives up on insisting on type checking for full-blown extensions, which includes checking for the appropriate version of a plugin dependency.

I'm not saying we should or need to change this mapping of strings to existing objects. I'm just documenting where the fragile bits of the codebase are, and talking about why we did it and what alternatives might be available.