debugging modules

John Barton johnjbarton at
Tue Jun 24 16:34:26 PDT 2014

On Tue, Jun 24, 2014 at 12:53 PM, Guy Bedford <guybedford at> wrote:

> If it is a tools problem, it becomes a much more complex problem.
> Firstly note that the promise isn't rejecting, it is resolving correctly.
> That is if I have a module X:
> X.js
> throw "this module throws";
> Then:
> System.import('X').then(function(m) {
>   // this returns correctly, with m defined.
> });
Surely this case must call reject().  What circumstances would call
reject() if not the failure to import?

> So the only information we have is the environment exception that
> something went wrong executing module X. We have no information of what
> dependency chain caused this.
> If we want to inspect the dependency chain, there is nothing to inspect,
> since we don't even know what loads might have caused it in the first place.
> So there is no way for a debugger to tell the user anything useful apart
> from inspecting the entire dependency tree. The evaluation chain that was
> an explicit set of modules for ensureEvaluated, is no longer available for
> useful debugging.

I don't follow all of this but using your example from
es6-module-loaders/test for import('load/main') dependent on
'load/depError' which throws 'dep error', then we should be able to give an
error like

Module Evaluation Error: 'dep error' in
loads/deperror loaded by

We can give line/col info with a bit of work in Traceur; it would be
trivial in a native implementation.

If the spec does not allow this, then we need to fix it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list