Module naming and declarations
claus.reinke at talk21.com
Fri May 10 01:01:44 PDT 2013
> My biggest concern is that people will assume a certain structure of the
> module path. Then they will assume that relative paths and logical names
> can be used interchangeably.
> E.g. if I'm inside of package "a/b.js" I can access a top level package
> using either "../backbone.js" or "backbone". I may even use both patterns
> in the same package.
> Most of the time it'll work because that file structure is common enough.
> That will eventually force everyone to use this file structure if they want
> to reuse modules that mix these patterns.
If I understand your concern correctly, that is just another variation of
the external reference/internal name overlap under discussion:
1 internal names, locally configured to map to external references,
are the recommended practice (ie, avoiding the path structure
dependencies you are concerned about is an education task)
2 some of us would like to ensure that both namespaces can be
identified unambiguously (ie, from looking at the module name,
it should be clear whether we're looking for an URL-referenced
file on disk or on the web, or for a locally configured/registered
One advantage of not separating internal and external names is that
you can take an existing project and reconfigure its module names,
to compensate for changes in directory structure or web locations
(even if the project imports directly from urls, you can rewrite and
redirect the import references).
An advantage of separating internal and external names is that you
can spell out best practices: avoid importing directly from external
references such as "url!http://path/to/jquery" or "url!file:path/to/jquery";
instead import from internal names and configure those to point
to external references. As long as the default loader passes through
"url!<some url>" as "<some url>", no confusion is possible about
whether an import uses an internal name or an external one. And if
best practices about keeping external references configurable are
followed, getting two external projects to match is a question of
matching their configuration data.
>From a readability and maintenance perspective, I prefer the latter.
It would also help with explaining the configuration idea and best
practices to JS coders. However, our module system champions
currently prefer the former (everything is an internal name and
can be configured).
More information about the es-discuss