App root module specifiers

Jordan Harband ljharb at
Sun Jun 4 22:27:59 UTC 2017

Indeed, module loading isn't really part of the language spec.

I think that you may want to submit a node.js enhancement proposal at - node would need to add something to
both current `require` and upcoming `import` to support having a "package
root" specifier; at which point transpilers and rewrite rules could convert
to whatever browsers (which have no concept of "package" in the first
place) need.

On Sun, Jun 4, 2017 at 10:42 AM, Darien Valentine <valentinium at>

> I’m not entirely certain of this, but I don’t think that the semantics of
> resolving a module specifier string are themselves a facet of the ES spec.
> However, I think the issue you’re describing may already be addressed in
> the implementations so far (Safari 10.1, Chrome Canary, FF Nightly) because
> the paths are treated like any other URI and can therefore begin with "/".
> So if we have a module at "" with the following
> content:
> ```
> import bar from 'bar.js'
> import baz from '/baz.js'
> ```
> ...then it looks for "" and "".
> I’m not sure if browsers are currently taking into account the `<base>`
> element when doing this, but this is the behavior I’ve observed so far, and
> it seems consistent with how other resource linking works in the browser
> (e.g. imports in CSS files).
> Node, which doesn't support `import` yet, maybe trained us a bit to see
> module specifiers a different way. I’m not sure what the solution will end
> up being there. The "/" is already taken to mean _system_ root rather than
> package root I think, and paths without any slashes have special resolution
> behavior that's nothing like URIs.
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list