Loader Hooks

[caridy]

No no, neither of those are real use-cases for the hooks IMO. Native modules are immutable, and you're not suppose to add new named exports dynamically because you loose the ability to statically verify them. In the case of the "path to file" (we call it `address`), you will have access to it thru the module metas (API pending to be defined). In the case of shims, you can do that by implementing a loader extension that uses a dynamic module to shim the access to a native one, the way we do this today is by hooking into the normalization process for dependencies, and replace the dep with the shim dep, e.g.:

* "foo" imports "bar"
* "bar-shim" imports "bar"
* "bar-shim" wraps all exports of "bar"
* the loader extension wire "foo" to consume "bar-shim" instead of "bar".

The same principle applies for alias, buckets, etc.

/caridy

On Jun 24, 2014, at 10:36 AM, Calvin Metcalf <calvin.metcalf at gmail.com> wrote:

> Say you wanted to add a hook which automatically added an export named filepath to a module is the path to the file, or add an import just for the side effects (say a shim or something).  The relevant code in es6 module loader is https://github.com/ModuleLoader/es6-module-loader/blob/master/lib/loader.js#L181-L256
> 
> 
> On Tue, Jun 24, 2014 at 10:33 AM, caridy <caridy at gmail.com> wrote:
> Calvin, I don't fully understand what you mean by "manipulate the exports and imports". I assume you're talking about native modules since you already have full control over the dynamic modules workflow. Maybe Guy Bedford can provide more details on how he implemented this process in es6-module-loader.
> 
> /caridy
> 
> On Jun 24, 2014, at 10:17 AM, Calvin Metcalf <calvin.metcalf at gmail.com> wrote:
> 
> > I've been doing work with the loader hooks and one gap that stands out is that there is no hook to let you manipulate the exports and imports of an module without parsing it yourself, in other words if you want to add, remove, or modify exports or imports of a module you have to write your own parsing function because the default instantiate function returns undefined.
> >
> > Ideas:
> >
> > - There is a way of doing what I need to do that I am missing.
> > - Add a post instantiate hook between 15.2.4.5.3 (InstantiateSucceeded) and 15.2.4.6 (ProcessLoadDependencies)
> > - The steps in 15.2.4.5.3.4 could be moved to the default instantiate function so that when overriding it you can still call it to get the parsed module object.
> >
> > ---
> > -Calvin W. Metcalf
> >
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> 
> 
> 
> 
> -- 
> -Calvin W. Metcalf

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140624/34095bda/attachment.html>