Module Loader Comments

Sam Tobin-Hochstadt samth at
Tue Mar 12 22:29:43 PDT 2013

On Tue, Mar 12, 2013 at 9:12 AM, Kevin Smith <khs4473 at> wrote:
> (Referencing
> When creating a custom loader, I believe there ought to be a way to fallback
> to using the parent loader's fetching behavior from within the fetch hook.
> After all, you might want to only override the parent loader's fetching
> behavior for a certain subset of resolved URLs.

The way to invoke the default behavior will be to just return
`undefined` from a hook (or fulfill with `undefined` for the fetch
hook).  We'll be updating the wiki in the next week or two with these
sorts of issues.

> If that feature is available, then I think we should consider eliminating
> the translate hook and instead allow translation semantics to be defined
> from within the fetch hook.

This won't work, for several reasons:

- It ought to be possible to override the translation behavior without
mucking with fetching.  Coffeescript translators don't need to perform
their own fetching.
- calls to `eval` go through the translate hook, but not through the
fetch hook, since there's nothing to fetch.

> - Aesthetically, we should keep the module loading kernel as small as
> possible.  Translation is really independent from module loading and we
> should probably push the concept of translation up to a higher layer if
> possible.

As simple as possible, but no simpler.  Loading is about how to turn a
reference to a module into the bytes of a JS program, and translation
fits right in there.  I'm not sure which other layer you're thinking

> - The current translate hook only provides URLs as input.  This might not be
> sufficient in some cases to determine the appropriate translation.  For
> example, we might want to use the value of a "Content-Type" HTTP header.  In
> such a scenario, the natural place to define that branching logic would be
> in the fetch hook, after retrieving the file using (X-Domain) HTTP requests.

Passing along this additional data may well be a good idea.  We plan
to make basically all the additional arguments to each hook into an
options object, and this would fit there.  Note that it wouldn't be
available always, though -- witness the case of `eval`.


More information about the es-discuss mailing list