Re: Loader Hooks
Another helpful place for a hook might be an executeDependencies type thing, currently the list of dependencies returned by instantiate are all loaded and ensureEvaluated is run on them, this makes sense for ES6 modules which always evaluate all dependencies before the module that depends on them, but it means you can't do an alternative evaluation strategy like running ensureEvaluated when the module is imported in the code (when using loading a module from some other system that works that way obviously), currently it's impossible to do that without loading your dependencies through some side channel which would likely break static checking of those dependencies. On Tue, Jun 24, 2014 at 2:16 PM, Juan Ignacio Dopazo wrote: > > > > On Tuesday, June 24, 2014 11:38 AM, Calvin Metcalf < > calvin.metc...@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 > > For this use case and other similar ones it'd be nice if the `metadata` > property of load records would be exposed as part of the modules metadata > in `this` or `Reflect.currentModule()`. > > or add an import just for the side effects (say a shim or something) > > We've been discussing conditional loading for shims and other similar > stuff at https://github.com/systemjs/systemjs/issues/9. > > Juan > > > > -- -Calvin W. Metcalf ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Loader Hooks
> > >On Tuesday, June 24, 2014 11:38 AM, Calvin Metcalf >wrote: > > >Say you wanted to add a hook which automatically added an export named >filepath to a module is the path to the file For this use case and other similar ones it'd be nice if the `metadata` property of load records would be exposed as part of the modules metadata in `this` or `Reflect.currentModule()`. or add an import just for the side effects (say a shim or something) We've been discussing conditional loading for shims and other similar stuff at https://github.com/systemjs/systemjs/issues/9. Juan___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Loader Hooks
We're also discussing ways of making these platform / environment dependencies work nicely. The hooks are asynchronous, so it is actually possible to import a module from within a hook like the locate hook in this case. Some combination of meta information and the above seems like it would work. On 24 June 2014 08:18, Calvin Metcalf wrote: > sorry I by shims I meant something like the es5-shim ( > https://github.com/es-shims/es5-shim) module as an example of something > to import that only had side effects, as for exports examples a hook that > looks for default exports of objects and added the objects properties as > named exports might be an example (aka a loader hook to do what is being > discussed right now on the other thread) or a hook to allow you to make a > mutable default export > > You are 100% correct that this screws up static analysis so it might be > better to think in terms of creating dynamic modules using the native > parser function then in terms of mutating modules, i.e. more like my third > suggestion then my second. > > > On Tue, Jun 24, 2014 at 10:56 AM, caridy wrote: > >> 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 >> 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 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 >>> 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@mozilla.org >>> > https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> >> >> -- >> -Calvin W. Metcalf >> >> >> > > > -- > -Calvin W. Metcalf > > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Loader Hooks
sorry I by shims I meant something like the es5-shim ( https://github.com/es-shims/es5-shim) module as an example of something to import that only had side effects, as for exports examples a hook that looks for default exports of objects and added the objects properties as named exports might be an example (aka a loader hook to do what is being discussed right now on the other thread) or a hook to allow you to make a mutable default export You are 100% correct that this screws up static analysis so it might be better to think in terms of creating dynamic modules using the native parser function then in terms of mutating modules, i.e. more like my third suggestion then my second. On Tue, Jun 24, 2014 at 10:56 AM, caridy wrote: > 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 > 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 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 >> 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@mozilla.org >> > https://mail.mozilla.org/listinfo/es-discuss >> >> > > > -- > -Calvin W. Metcalf > > > -- -Calvin W. Metcalf ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Loader Hooks
Guy Bedford's es6-module-loader follows the Loader spec closely. I just refactored it to create a function call `parse(load) -> deps`: https://github.com/ModuleLoader/es6-module-loader/blob/master/lib/loader.js#L389 This location in the pipeline is pretty much where you suggest. I think I've convinced Guy to let me add it as a hook. Maybe your request will push him over the edge ;-) Note that as far as I can tell, this function call provides a neat interface between the Loader and parser. jjb On Tue, Jun 24, 2014 at 7:17 AM, Calvin Metcalf 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@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Loader Hooks
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 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 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 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@mozilla.org > > https://mail.mozilla.org/listinfo/es-discuss > > > > > -- > -Calvin W. Metcalf ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Loader Hooks
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 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 > 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@mozilla.org > > https://mail.mozilla.org/listinfo/es-discuss > > -- -Calvin W. Metcalf ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Loader Hooks
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 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@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
