Always load single instance of library

[Nathan Friend]

I have two jspm modules, ModuleA and ModuleB.  Both require the d3.js library.  I have a third module, ModuleC, which requires ModuleA and ModuleB.  Both ModuleA and ModuleB work in isolation, but when ModuleC is run, several d3 errors are thrown.  So far as I can tell, this is because d3.js is being loaded twice when ModuleC is run - ModuleA and ModuleB both receive their own instance of d3.  ModuleA relies on a d3 plugin (nvd3) that adds functionality to the d3 instance.  When ModuleB loads, it replaces the d3 instance (that has the plugin functionality added) with a fresh version of d3 that doesn't have the plugin loaded.

How can I configure SystemJS to always provide the same instance of d3 when the library is imported?  The goal would be to have ModuleA and ModuleB both receive the same instance of d3 when they "import d3 from 'd3'".

[Olivier Ligot]

Hi,

This may be caused by different versions of D3 being loaded in your app. 

Suppose ModuleA uses D3 version 3.5.15 while ModuleB uses D3 versions 3.5.17. This means both versions will be loaded by SystemJS and there won't be a single (shared) instance in your app.

One way to find out if it's the case is to run the command 

> jspm inspect

and look if the D3 library has 2 different versions.

If you control ModuleA and ModuleB, you can then change one to use the same version as the other. That way, only one instance will be loaded and your problem should be resolved.

Note that with jspm 0.17 (which is currently in beta), you could use peer dependencies for D3, as explained here: http://jspm.io/0.17-beta-guide/peer-dependencies.html

Also note that there is an open pull request to enhance the jspm inspect command (https://github.com/jspm/jspm-cli/pull/1968), so that it only shows dependencies which have multiple versions, as well as telling you from where it comes from (i.e. which parent has which version of the dependency, in your case, this would be ModuleA and ModuleB).

Hope this helps,

Olivier

[Nathan Friend]

Awesome, thanks for the help Olivier.  This was basically the problem, although it was a little more nuanced.  Both modules were using the same version of d3 (3.5.17), but one was fetching it from GitHub while the other was fetching it from npm.  This was happening because one of the modules was requiring d3 directly (which had installed from GitHub), while the other was requiring it indirectly through angular-nvd3 (while eventually resolved to the npm version of d3).  Once I coerced both modules to use the npm version, this issue went away.

Is there a way to prevent this kind of thing from happening in the future?  I think issue has already been discussed a bit here: https://github.com/jspm/jspm-cli/issues/716.

[Guy Bedford]

It's important to see this as an ecosystem problem on jspm, where we should use the same registry for all versions of d3 in the jspm registry.

What was it that was using d3 from github in the first place? That sounds like it may be a registry override doing that that we can potentially change the reference for.

--
You received this message because you are subscribed to the Google Groups "jspm" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jspm-io+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nathan Friend]

I was under the impression that my team member ran "jspm install d3" which automatically pulled from GitHub.  However, I just tried this in a new, empty jspm project and d3 was installed from npm.  That makes me think that my team member actually ran "jspm install github:d3/d3" while trying install d3.