Prefer already-loaded modules?

[blink1073]

If we have already loaded a module that meets a semver requirement, should we prefer that to one that has not yet been loaded? This would come up if we load a bundle after the initial load that has a newer version of a package that was already loaded.

[willingc]

🐔 🥚 or 🥚 🐔

[blink1073]

Hahaha, truth.

[jasongrout]

A subtlety here is that since the loading mechanism caches versions at the file level instead of the package level, you could have package A loading one file from package B version 1.0.0, and then someone loads package B version 1.1.0, and package A would load any new files from package B version 1.1.0. This could really be bad, since there are no guarantees in semver about how file implementations in a single package interact with each other across versions.

[blink1073]

We are slowly starting to realize that packages with multiple entry points do not play well with this extension mechanism. We can fix this in Phosphor and JupyterLab by creating sub-packages (copying the model used by Angular), but it won't help us with third party libs like CodeMirror and MathJax.

[jasongrout]

I think giving very verbose warnings anytime we have files shadowing other files would go a long way towards understanding how the system is working. We can detect that when they are added to the extension mechanism. We could also cache the semver -> version number mapping per package instead of per file like we do now.

[jasongrout]

I think giving very verbose warnings anytime we have files shadowing other files would go a long way towards understanding how the system is working.

Hmm, that's probably overly verbose. Perhaps a warning anytime the same semver will return a different version of a package.

[blink1073]

I don't fully follow what you mean, we probably need to discuss this live.