App root module specifiers
ljharb at gmail.com
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
https://github.com/nodejs/node-eps - 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
On Sun, Jun 4, 2017 at 10:42 AM, Darien Valentine <valentinium at gmail.com>
> 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 "www.host.foo/foo/foo.js" with the following
> import bar from 'bar.js'
> import baz from '/baz.js'
> ...then it looks for "www.host.foo/foo/bar.js" and "www.host.foo/baz.js".
> 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 mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss