Discuss
  • module path resolution

module path resolution

# Irakli Gozalishvili (13 years ago)

I'v being trying to figure out how ES.next module path resolution would work. Unfortunately proposal is not very clear about it: harmony:modules

Here are some of the questions I have:

  1. Will html base element have a same effect on modules as it has on script tags today ?
  2. Are relative paths resolved to a requirer's url, owner html document's urlor baseURI ?

If my assumptions are correct this little example is correct: Gozala/packageless/tree/master/examples/es.next

-- Irakli Gozalishvili Web: www.jeditoolkit.com

# David Bruant (13 years ago)

Le 23/03/2012 20:05, Irakli Gozalishvili a écrit :

I'v being trying to figure out how ES.next module path resolution would work. Unfortunately proposal is not very clear about it: harmony:modules

I think that a behavior that would make sense could be:

  1. If a script inserts a module, this script path (URL or file system path or whatever) should be the base of relative module paths.
  2. If the script has no path, let the platform decide of the behavior. In the case of inline JavaScript in HTML, using the HTML base URL seems appropriate (which depends on the base element if present).

Here are some of the questions I have:

  1. Will html [base element] have a same effect on modules as it has on script tags today ?

I would answer yes for inline scripts.

  1. Are relative paths resolved to a requirer's url, owner html document's urlor baseURI ?

I would answer that if the requirer has a path, then this path should be used. If it doesn't, it's platform dependent and in the case of HTML, it would be the base document URL, which is dependent on the base element.

Does that make sense?

# David Herman (13 years ago)

On Mar 23, 2012, at 5:05 PM, Irakli Gozalishvili wrote:

I'v being trying to figure out how ES.next module path resolution would work. Unfortunately proposal is not very clear about it: harmony:modules

There's more info about the resolution semantics on the loaders page:

http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders

Basically loaders make it possible for programmers to create custom resolution policies.

But your question is probably more about what the default policy of the System loader will be on the web. First of all, the System loader's baseURL (should it be baseURI? I never understood the difference) would come from the document's URL. So relative would definitely be relative the HTML file.

Here are some of the questions I have:

  1. Will html base element have a same effect on modules as it has on script tags today ?
  2. Are relative paths resolved to a requirer's url, owner html document's urlor baseURI ?

If my assumptions are correct this little example is correct: Gozala/packageless/tree/master/examples/es.next

These are really good points I hadn't thought about. Thanks for bringing it up! I like the idea that

./foo.js

forces the loading to be relative to the document, whereas

bar/baz.js

is interpreted as relative to the <base> path. I don't have strong feelings myself about what the System loader's policy should be on the web, but I want to make sure our infrastructure is flexible enough to support a) whatever everyone decides is the best policy for the browser, and b) policies like the Node.js / NPM policy. I will have to read up a little more on document.baseURI and <base> and all that.

Thanks for the information and ideas!

# Irakli Gozalishvili (13 years ago)

On Friday, 2012-03-23 at 18:14 , David Herman wrote:

On Mar 23, 2012, at 5:05 PM, Irakli Gozalishvili wrote:

I'v being trying to figure out how ES.next module path resolution would work. Unfortunately proposal is not very clear about it: harmony:modules

There's more info about the resolution semantics on the loaders page:

harmony:module_loaders

Basically loaders make it possible for programmers to create custom resolution policies.

But your question is probably more about what the default policy of the System loader will be on the web.

Yeap!

First of all, the System loader's baseURL (should it be baseURI? I never understood the difference) would come from the document's URL. So relative would definitely be relative the HTML file.

Yeah so by default document.baseURI is just a document.documentURI or simply URL to the html document. All the relative URLs on that document resolve to the document.baseURI. Also, there is an html base tag that allows one to set value of document.baseURI and there for change relative url resolution. More details can be found in HTML spec: www.w3.org/TR/html401/struct/links.html#h-12.4

Here are some of the questions I have:

  1. Will html base element have a same effect on modules as it has on script tags today ?
  2. Are relative paths resolved to a requirer's url, owner html document's urlor baseURI ?

If my assumptions are correct this little example is correct: Gozala/packageless/tree/master/examples/es.next

These are really good points I hadn't thought about. Thanks for bringing it up! I like the idea that

./foo.js

forces the loading to be relative to the document, whereas

bar/baz.js

is interpreted as relative to the <base> path. I don't have strong feelings myself about what the System loader's policy should be on the web, but I want to make sure our infrastructure is flexible enough to support a) whatever everyone decides is the best policy for the browser, and b) policies like the Node.js / NPM policy. I will have to read up a little more on document.baseURI and <base> and all that.

Let me elaborate a bit on what my intent is:

Usually any app / lib code is organized such that third party dependencies are located in an separate directory from an actual program code. This helps to reduce noise for a human eye and also make it easier to work with version control systems, since third party code is commonly not tracked in the same repository. I think it's pretty important to have good support for this. One cleanest way IMO would be to have different resolution login for dependencies:

A. ./foo.js ../foo/bar.js B. foo.js, foo/bar.js

I'd suggest to resolve A type paths relative to a requirer (ether require module url, or document url). And resolve B type paths relative to a document.baseURI. That would allow users to organize codebase as described above and show in the example repo: Gozala/packageless/tree/master/examples/es.next

Also not that this is somewhat similar to nodejs behavior where ./foo, ../foo/bar form is used for resolving modules relative to the requirer. While foo, foo/bar form is used for installed package dependencies. Unfortunately nodejs policies are bit more complicated than that since foo form there won't look in just one baseURL instead it does recursive upward search in node_modules folders which I don't think is compliant with web. That being said though I think it would map simple cases pretty well.

# John J Barton (13 years ago)

On Fri, Mar 23, 2012 at 6:14 PM, David Herman <dherman at mozilla.com> wrote:

On Mar 23, 2012, at 5:05 PM, Irakli Gozalishvili wrote: But your question is probably more about what the default policy of the System loader will be on the web. First of all, the System loader's baseURL (should it be baseURI? I never understood the difference) would come from the document's URL. So relative would definitely be relative the HTML file.

Please look at James Burke's work on require.js. He took at lot of input, looked at a lot of issues around paths, and his system is the standard in practice.

jjb

# Wes Garland (13 years ago)

On 23 March 2012 21:59, Irakli Gozalishvili <rfobic at gmail.com> wrote:

A. ./foo.js ../foo/bar.js B. foo.js, foo/bar.js

I'd suggest to resolve A type paths relative to a requirer (ether require module url, or document url). And resolve B type paths relative to a document.baseURI.

This is almost what CommonJS specifies and is quite close to what we use locally. We have a top-level path that is prepended to type B require statements which is by default calculated from window.location.href. We can, of course, override it, in case we move the page to a location where this calculation does not work -- exactly analogous to a <base href>

setting.

The fact that the modules themselves use relative paths to co-dependencies means that it's easy to move modules around, from app to app, server to server, etc.

One thing that would be nice that we don't currently have is the ability to load modules relative to the calling web page. This is an oversight in our loader.

# Axel Rauschmayer (13 years ago)

One thing that would be nice that we don't currently have is the ability to load modules relative to the calling web page. This is an oversight in our loader.

I'm curious: What is the use case for that?

[[[Sent from a mobile device. Please forgive brevity and typos.]]]

Dr. Axel Rauschmayer axel at rauschma.de Home: rauschma.de Blog: 2ality.com

# Wes Garland (13 years ago)

On 25 March 2012 03:07, Axel Rauschmayer <axel at rauschma.de> wrote:

One thing that would be nice that we don't currently have is the ability to load modules relative to the calling web page. This is an oversight in our loader.

I'm curious: What is the use case for that?

The case where you have two web pages loading mutually-shared JS -- or even one page using a lot of JS -- but not code you want to place in the globally-available library directory for whatever reason.

We write web apps, and think of HTML files more or less as "programs". Local-dir modules are like extra .o files in a C program. Module-dir modules are like libraries in /usr/lib. The "main()" function is a module contained within the HTML itself, usually between </body> and </html>.

Another use-case our loader doesn't address well is loading dynamically-generated modules. These are modules whose source code is generated on the fly for whatever reason (e.g. they might emit information from a database, crypto secrets, etc.). We have to do either

require("../../methods/module") /* brittle / or require("/" + window.location.hostname + "/methods/module") / annoying */

# Axel Rauschmayer (13 years ago)

Right. I also like Node’s idea of “global module names”, where a module name is a location-independent identifier, for a module that might be installed locally or globally. It might make sense to use a variable name for “relative to the HTML page”, e.g. "$BASE/methods/module". That would be more explicit than a convention on how to write the path.

# John J Barton (13 years ago)

On Sun, Mar 25, 2012 at 10:09 AM, Axel Rauschmayer <axel at rauschma.de> wrote:

Right. I also like Node’s idea of “global module names”, where a module name is a location-independent identifier, for a module that might be installed locally or globally.

I'm not sure what you mean by 'module names'. harmony:modules says: "External modules do not name themselves"

One effective strategy for referencing modules combines a variable path with a well-known identifier. For example: 'array-strategies/SparseArray'. The variable path, 'array-strategies', can be bound to a library path at build or load time. The well-known name then selects the corresponding entry from the library. This insulates the dependent module from path changes but keeps the granularity of the redirection manageable. The variable-path may have lots of silly ../../ridiculousLongPathSegements/etc/etc, but this junk is isolated to the main loading-control script.

Using single word names for module specifiers means every module has to be redirected. Multi-word names require more understanding when writing the redirection paths. Two parts make a good compromise.

It might make sense to use a variable name for “relative to the HTML page”, e.g. "$BASE/methods/module". That would be more explicit than a convention on how to write the path.

Surely we would use JS functions or properties on the system loader rather than string substitution right?

jjb