js-loaders
js-loaders copied to clipboard
Pseudoimplementation of the proposed ES6 module loaders.
From tracuer's point of view it looks like the Loader(options) callback list is missing some calls: these look like operations the compiler should perform: ``` js let body = $ParseModule(loader,...
Both URLs and file systems allow 'a/../b' in relative paths. Canonicalization of such paths routinely give results devs expect. Copy and pasting relative paths from other development tools into module...
Using an object as the second argument to System.normalize adds complexity without value. The relevant data for normalize is the importingModuleName, the reference for the name to normalize against.
These seem like identifiers that ought to be illegal to avoid confusing errors.
As far as I can tell, the first argument to System.resolve() must be normalized, so everywhere we want to resolve we have to write something like: ``` js function normalResolve(name,...
``` samth: so does global.eval also go through the translate hook? ...even direct eval? jorendorff: yes well, i think so i seem to recall dherman disagreeing ``` (2013 April 22)...
- The return type is confusing - The name is misleading (it's not doing linking, but rather providing information used later for linking)
If a link hook returns a Module, do we commit that to the registry immediately, even though other modules in the same linkage unit may not have loaded yet?
Per @samth, in the browser, cross-origin `` loads do go through the `fetch` hook, but they quietly skip the `translate` and `link` hooks. (This is to avoid revealing cross-origin text...
@samth has proposed that the if you pass `{module: "x/y"}` as the `options` argument to `loader.eval()`, the loader hooks should receive `options.referer.name === "x/y"` rather than null. In the browser,...