Relative path lookup doesn't work as expected

[matthewp]

You should be able to do this:

<script>
  System.paths['one'] = 'path/to/one.js';
  System.import('one');
</script>

one.js

define(['./two'], function(two) {
  // do something with two
});

It should look up the path to two relative to the load.address of one. Instead it tries to load two from the baseURL.

If this is a es6-module-loader issue forgive me and I'll file there.

[matthewp]

I've pushed a breaking test to my fork.

[guybedford]

Yes, normalization is name-relative not address-relative.

The good news is that names are becoming full URLs, pending ModuleLoader/es-module-loader#218 so then this will work in the next big breaking change coming soon.

[guybedford]

Thanks for patience here... I hate to keep mentioning the elusive updates, but trying to get these changes through in one go if possible.

[matthewp]

Can you make sure there is a test for this bug? I'm not sure why that issue will fix this, if normalization is still name-relative.

[guybedford]

Paths will be renamed to site in ES6 Module Loader and happen at normalization not locate.

[matthewp]

Is that a no to adding a test?

[guybedford]

This is not really a bug, this is completely as designed in the current paths model. The model is changing though, and the new model will have tests.

[matthewp]

As long as it is tested!

[justinbmeyer]

@guybedford @matthewp This isn't a bug .. it's a feature. This is a trade off between:

• the power of a "pure" normalized moduleName namespace (like RequireJS has)
• simplicity of resource-based moduleNames (like CJS)

As ES6ML needs to be in the browser, I think it is making a mistake losing the power of a pure normalized namespace for the simplicity of a resource-based moduleNames.