Module naming and declarations

James Burke jrburke at gmail.com
Wed May 8 11:47:35 PDT 2013


On Wed, May 8, 2013 at 10:44 AM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:
> How is this in disagreement with what Jason said?  His point is that
> if you're in the module "a/b/c", "./controllers" refers to
> "a/b/controllers", and "backbone" refers to "backbone". Once you have
> a module name, there's a default resolution semantics to produce a URL
> for the fetch hook, which you describe accurately.

For a developer coming from Node, this may be slightly new to them,
and I think when Jason mentions "package", it may not all fit together
with how they understand Node to work. Here is a shot at trying to
bridge that gap:

Node resolves relative IDs relative to the path for the reference
module, and not relative to the reference module's ID. This is a
subtle distinction, but one where node and AMD systems differ. AMD
resolves relative IDs relative to reference module ID, then translates
that to a path, similar to what Sam describes above.

I believe Node's behavior mainly falls out from Node using the path to
store the module export instead of the ID, and it makes it easier to
support the nested node_modules case, and the package.json "main"
introspection.

However, that approach is not a good one for the browser, where
concatenation should preserve logical IDs not use paths for IDs. This
allows disparate concatenated bundles and CDN-loaded resources to
coordinate.

For ES modules and Node's directory+package.json main property
resolution, I expect it would work something like this:

Node would supply a Module Loader instance with some normalize and
resolve hooks such that 'backbone' is normalized to the module ID
'backbone/backbone' after reading the backbone/package.json file's
main property that points to 'backbone.js'. The custom resolver maps
'backbone'/backbone' to the node_modules/backbone/backbone.js file.
For nested node_modules case, Node could decide to either make new
Module Loader instances seeded with the parent instance's data, or
just expand the IDs to be unique to include the nested "node_modules"
directory in the normalized logical ID name.

If 'backbone', expanded to 'backbone/backbone' after
directory/package.json scanning, asked for an import via a relative
ID, './other', that could still be resolved to 'backbone/other', which
would be found inside the "package" folder. So I think it works out.

James


More information about the es-discuss mailing list