to be honest I think that `.file` and `.line` would cover the "who imported what" scenario but those look like a very good/complete `.message` for such error, nice job
On Fri, Nov 21, 2014 at 3:37 PM, John Barton <[email protected]> wrote: > Traceur reports such errors like this: > > // Error: File not found 'feature/Modules/resources/no_such_file.js' > // Error: Specified as ./resources/no_such_file.js. > // Error: Imported by > feature/Modules/Error_InvalidModuleDeclaration.module.js. > // Error: Normalizes to feature/Modules/resources/no_such_file.js > // Error: locate resolved against base './' > > import * as b from './resources/no_such_file.js'; > > jjb > > On Fri, Nov 21, 2014 at 3:49 AM, Marius Gundersen <[email protected]> > wrote: > >> >> >> On Fri, Nov 21, 2014 at 11:49 AM, Andrea Giammarchi < >> [email protected]> wrote: >> >>> a native ImportError seems to me the best option and it's also easy to >>> polyfill in a meaningful way with all current module loaders used already >>> out there. >>> >>> >> My experience with AMD and require.js is that it is very useful for the >> error to include not only the module that couldn't be loaded but also the >> module that requested it. These two fields should be on the Error object, >> and so a new ImportError with the field `missingModule` and `requestedBy` >> (or something similar) sounds like a good solution to me. >> >> Marius Gundersen >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
