module path resolution

John J Barton johnjbarton at
Sun Mar 25 12:49:16 PDT 2012

On Sun, Mar 25, 2012 at 10:09 AM, Axel Rauschmayer <axel at> wrote:

> Right. I also like Node’s idea of “global module names”, where a module
> name is a location-independent identifier, for a module that might be
> installed locally or globally.

I'm not sure what you mean by 'module names'. says:
  "External modules do not name themselves"

One effective strategy for referencing modules combines a variable path
with a well-known identifier. For example: 'array-strategies/SparseArray'.
The variable path, 'array-strategies', can be bound to a library path at
build or load time. The well-known name then selects the corresponding
entry from the library. This insulates the dependent module from path
changes but keeps the granularity of the redirection manageable.  The
variable-path may have lots of silly
../../ridiculousLongPathSegements/etc/etc, but this junk is isolated to the
main loading-control script.

Using single word names for module specifiers means every module has to be
redirected. Multi-word names require more understanding when writing the
redirection paths. Two parts make a good compromise.

> It might make sense to use a variable name for “relative to the HTML
> page”, e.g. "$BASE/methods/module". That would be more explicit than a
> convention on how to write the path.

Surely we would use JS functions or properties on the system loader rather
than string substitution right?


> On Mar 25, 2012, at 17:42 , Wes Garland wrote:
> On 25 March 2012 03:07, Axel Rauschmayer <axel at> wrote:
>> One thing that would be nice that we don't currently have is the ability
>> to load modules relative to the calling web page.  This is an oversight in
>> our loader.
>> I'm curious: What is the use case for that?
> The case where you have two web pages loading mutually-shared JS -- or
> even one page using a lot of JS -- but not code you want to place in the
> globally-available library directory for whatever reason.
> We write web apps, and think of HTML files more or less as "programs".
> Local-dir modules are like extra .o files in a C program.  Module-dir
> modules are like libraries in /usr/lib.  The "main()" function is a module
> contained within the HTML itself, usually between </body> and </html>.
> Another use-case our loader doesn't address well is loading
> dynamically-generated modules.  These are modules whose source code is
> generated on the fly for whatever reason (e.g. they might emit information
> from a database, crypto secrets, etc.).  We have to do either
> require("../../methods/module")   /* brittle */
> or
> require("/" + window.location.hostname + "/methods/module")  /* annoying */
> Wes
> --
> Wesley W. Garland
> Director, Product Development
> PageMail, Inc.
> +1 613 542 2787 x 102
> --
> Dr. Axel Rauschmayer
> axel at
> home:
> twitter:
> blog:
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list