Error loading module when already loading

[dtinth]

• I installed npm:midievents and npm:midifile from jspm.

• npm:midifile depends on npm:midievents.

• I use this code, it works fine:

  import MIDIFile from "npm:midifile"
  import MIDIEvents from "npm:midievents"

• I ran jspm depcache midifile and jspm depcache midievents.

• The same code, this error is shown:

  Potentially unhandled rejection [2] TypeError: "npm:midievents@0.1.0" already loading
      at c.loader (http://localhost:9000/jspm_packages/es6-module-loader.js:7:14642)
      at c (http://localhost:9000/jspm_packages/es6-module-loader.js:7:4358)
      at new b (http://localhost:9000/jspm_packages/es6-module-loader.js:7:4244)
      at b (http://localhost:9000/jspm_packages/es6-module-loader.js:7:12639)
      at x.load (http://localhost:9000/jspm_packages/es6-module-loader.js:7:21156)
      at x.$__global.upgradeSystemLoader.e.locate (http://localhost:9000/jspm_packages/system.js:1:20693)
      at http://localhost:9000/jspm_packages/es6-module-loader.js:7:13118
      at O (http://localhost:9000/jspm_packages/es6-module-loader.js:7:7222)
      at K (http://localhost:9000/jspm_packages/es6-module-loader.js:7:6854)
      at y.6.y.when (http://localhost:9000/jspm_packages/es6-module-loader.js:7:10008)
  

  Note that event with source maps, es6-module-loader does not produce a useful stack trace.

• This may be related to https://github.com/ModuleLoader/es6-module-loader/blob/b3f641b615a82df0e13fceee3c91d4f15c35918a/src/loader.js#L344.

• Is there any fix for this?

[guybedford]

Sorry about the issue. This could be an asynchronous condition yes. I'm going to leave this up and aim to fix it soon, but it may be a few weeks unfortunately.

[guybedford]

Yes this is exactly the issue on line 344. I'm looking into a fix.

[guybedford]

Thanks again for the incredibly clear steps to reproduce this. Was an easier fix than expected after all!

[marcfallows]

Not sure this is completely fixed.

If I have a module (a) which depends on another module (b) and I require both modules (while b is still loading), I end up getting a back when expecting b.

Note: This behaviour is observed in a more complex project so it is possible the root cause is more complex. As best as I can tell, this is the underlying issue.

// a.js
define(["b"], function(b) {
   // ...
});

// main.js
require("a");
require("b", function(b){
   // if "b" was already loading when I called require what I get back is actually "a"
});

I think loader.loads[i].linkSets[0].done may be a bit too simple in https://github.com/ModuleLoader/es6-module-loader/blob/9ab7cfc6dc9304666c23ab2f3e9380017a87b630/src/loader.js#L348

In this case loader.loads[i].linkSets[0] will have 2 values in the loads property, the first one for a and the second one for b, and done gives me back a.

I've looked into it, but I get a bit confused with the loads/linkSets nesting but maybe you could provide some direction.

[guybedford]

@marcfallows thanks so much, it seems like you've traced the issue exactly here. The first load is reliably the load responsible for the linkset, but the first linkset is not reliably the load. I'm looking into this.

[guybedford]

@marcfallows I'm still struggling to replicate this. The linkSet is definitely resolving to its correct starting load due to https://github.com/ModuleLoader/es6-module-loader/blob/9ab7cfc6dc9304666c23ab2f3e9380017a87b630/src/loader.js#L490.

This may well be something else. My first thought would be to ensure your sources are not being detected as CommonJS instead of AMD with the use of the require statement? Perhaps try adding "format amd" to the top of the source to ensure this doesn't happen.

[marcfallows]

@guybedford I wasn't able to repro in a Plunker using my simplified case either. In fact, I wasn't able to repro the OP's original issue in a simple Plunker either (although I was seeing the issue in my project). I'll try to come up with something today. Do you have a simple repro for the original "already loading" issue?

The sources are definitely being detected as amd (all scripts lead with a define).

It may be worth noting that:
loader.loads[i].name != loader.loads[i].linkSets[0].startingLoad.name
I would have expected these to match if we are relying on loader.loads[i].linkSets[0].done

i.e. in my case:
i == 2
loader.loads[i].name == "lib/sdk@0.25.15/models/Product"
loader.loads[i].linkSets[0].startingLoad.name == "lib/sdk@0.25.15/models/ProductList"

A few other possibly helpful bits of information:
loader.loads[0].name== "lib/sdk@0.25.15/models/ProductList" - Which depends on Product
loader.loads[0].status == "loaded"
loader.loads[i].status == "loading"

Any debugging help would be appreciated if you have any ideas on where to look.

[marcfallows]

@guybedford I can track it down as far as this line https://github.com/ModuleLoader/es6-module-loader/blob/05e0c5abeeac9dfd70d731d17aa7adbe156bf884/src/loader.js#L291

Where I have the following:
load.name == "lib/sdk@0.25.15/models/ProductList"
depLoad.name == "lib/sdk@0.25.15/models/Product"

So, when it calls addLoadToLinkSet this line https://github.com/ModuleLoader/es6-module-loader/blob/05e0c5abeeac9dfd70d731d17aa7adbe156bf884/src/loader.js#L402 causes the depLoad to inherit the startingLoad of the other module (it simply pushes the linkSet to it's own linkSets collection - which is empty so it becomes the first item). So the "done" promise for the first item in the linkSets collection is actually from the other module.