For example, if B depends on A@1.x.x and C depends on A@2.x.x, what happens? Will Meteor ever get both versions of the dependency to satisfy both packages (a dependency fork)?
No. There is always a single version of a package in an app and it is determined by the constraint solver.
Generally, it targets optimization based on a number of metrics. You can read up on how it works here:
1 Like
Ah, Meteor calls it “multiple loading”. Thanks! It makes sense to allow multiple loading for certain libraries, like underscore for example. The underscore methods are all one-shot methods that don’t impact state anywhere else in underscore itself.
But what happens if 3 different versions of underscore are included and they all get sent to the client? What if at the same time multiple versions of other client libraries are also sent to the client and the browser then needs to load megasillybytes of data 
@serkandurusoy
Haha, yeah. 
The size would be bigger but everything would still work fine. If Meteor would be more conventional with it’s packaging system (perhaps adopting something like Webpack) then there would be the benefits of dead-code elimination, module imports and exports with CJS or ES6 Modules, etc, so it’d be easy to eliminate code that isn’t used in from all three versions of underscore in which case you would likely end up with final code that is smaller than a single full version of underscore. JSPM implements the full ES6 Module spec over HTTP/2 for lazy loading (which is how ES6 Modules will be in the near future!), so pieces of all three versions of underscore could be sent only when needed instead of all at the same time during initial page load.
Well, yes, but it is a draft spec and meteor is no longer a 0.x platform and requires stability. Perhaps when ES6 actually sees the light of day. But yeah, it would be awesome.
1 Like