Jlab automatically deduplicates threejs if the versions overlap. That's part of the big reason for the build step.

great, that's progress, but still built into vendor~main is still quite brutal. Working through it locally, will have some results in a tick...

Just because i looked:

ipyvolume    "three": "^0.97.0",
bqplot       "three": "^0.91.0",
pythreejs    "three": "^0.97.0",

So, hooray 🎉!

Here's the situation as of 8b1935e:

1.2M Aug 12 16:26 vendors~bqplot.a07da31a0075a039c91a.js
4.4M Aug 12 16:26 vendors~main.881efab41eb56f4e4f00.js

I don't actually know where threejs went, as I can't see it in stats, but it's working fine:

Of additional concern is the extra copy of @lumino/widgets... but I assume there's a good, known reason for it.

I don't actually know where threejs went

Perhaps it was split out to a different file now? Those choices are made automatically at build time, so adding an extension may lead to some different division.

The extension system rework in jlab 3 leads to more things being split out (and shared)

Of additional concern is the extra copy of @lumino/widgets... but I assume there's a good, known reason for it.

There shouldn't be two copies of lumino widgets, as far as I know, so I think that is indeed a cause for concern.

On the duplicate widgets: that was already appearing in the downstream where i found the issue, but the two copies appeared in main (of course)... having it split out has just isolated the symptom, I'm fairly sure I didn't create it.

For reference, a vanilla build only includes the index.es6.js

I tried a couple alternate import mechanisms to get at the "real" MessageLoop/Widget, and it's always still pulling its own copy in. While I think it would be possible to get at the Widget class from some part of @jupyter-widgets/base or controls or something, I don't see a way to get at MessageLoop, as it's basically only ever used statically. Seems like some of these things could be re-exported/normalized in an upstream... it hardly seems like "just an implementation detail" at this point...

anyhow: approaches tried

• import the whole module to get closer to the regex spec
  • no change
• peerDependencies on phosphor
  • no change
• try to get the Widget/MessageLoop out of base/controls
  • can't figure out how

Yeah, fiddled with some other stuff, no change. I don't think it can be solved from this side, short of changing the phosphumino dependency, which i assume is done to avoid having to maintain separate releases. I'm not entirely sure it's worth fixing this in Lab2 if it hasn't actually been creating problems...

As i haven't had to fire up the webpack visualizer in ages (thank GOODNESS), here's a simpler table of the load impact:

I've gotta think reducing initial load to 2 requests of ~30k on page setup vs all 11 of ~ 1.3mb is worth the hassle.

Have repushed with various updates: it builds/runs locally on Ubuntu, and the tests pass on chromium 98.

guess i'd like to see what CI says before sinking any more time!

Thanks @bollwyvl, just approved the CI

@martinRenou thanks!

it's pleasing it worked right off the bat. I really don't think anything in there constitutes an even noticeable change to downstreams, but certainly welcome feedback. I'll have a look at some of those other ones!

Thanks!!