Module naming and declarations
samth at ccs.neu.edu
Fri Apr 26 22:52:00 PDT 2013
On Sat, Apr 27, 2013 at 12:22 AM, Kevin Smith <zenparsing at gmail.com> wrote:
>> And note that Java also does not mandate reverse-DNS, it's just a
>> convention. But in fact, that convention is really annoying and people hate
>> it. Node uses much simpler global names that are reserved via NPM. This does
>> lead to collisions and some people don't like that; an alternative system
>> could use usernames. These are all viable alternatives, and what will really
>> be needed will be package management systems like NPM for the web. What we
>> are creating here is the basic semantics that provides a way for people to
>> refer to shared modules. People can and should build package management
>> systems, including tools, servers, and web sites, on top of this.
> Let see how we might build package systems on top of this. Let's say that I
> want to create a package management system named "browserpm". Now, since I
> don't want any of my names conflicting with some other PM's names, the
> logical name for modules within my registry will need to include the
> registry name itself:
> import something from "browserpm/taskjs";
Why would you need to worry about this, though? I've never seen a
language (or other software infrastructure) where people built systems
using multiple package managers at once. For example, Macs have an
unfortunate multiplicity of package systems, but you don't have a brew
package depend on a macports package. The point of a package system is
to fetch and setup the code, not to sit there in the names of your
modules. This is made especially clear if you think about the source
of a library. Is every library going to be rewritten for every
Certainly, existing JS package management systems don't work this way.
I've in fact worked with a system that was a lot like this, in that
the package manager was part of the import statement. We didn't like
it, and we're replacing it with a more NPM-like system.
> This looks *almost* like a real URL. Why not just use a URL instead?
> import something from "//browserpm.org/taskjs";
> I could even serve the source code directly from the "browserpm.org" site.
> If we want to load scripts from our local server, we would just override the
> module URL resolution algorithm:
> "//browserpm.org/taskjs" => "/modules/browserpm.org/taskjs";
> It seems to me that, *long term*, URLs provide all of the advantages of
> "logical names", without the downside of sacrificing one of the core
> principles of the web: namely, that resources are represented by URLs.
The URLs you're proposing here just *are* logical names, and they
aren't in most cases being dereferenced to produce resources, which is
the core point of URLs on the web. They're just inconvenient logical
More information about the es-discuss