Does not have the path in the latest version

[Vaccano]

I was using this to support custom file names for my views and view models.

Basically If I had the following file names:

• widget.ts
• widget.html

I could use this library so that I could have the following file names instead:

• widget-vm.ts
• widget-view.html

This is useful if I have an entity called widget.ts that stores what a widget is to my application.

I just upgraded from aurelia-html-import-template-loader@1.0.0-beta.1 to aurelia-html-import-template-loader@1.0.0-beta.1.1.2 and this code broke. The issue is that origin.moduleId used to be the path + file name + extension.

Now it is just file name. I don't really need the extension. But I need the path, unless I want to have all my file locations on the root 👎

I can roll back, but I am hopping for a non-breaking version in a future release.

Here is my code that I was using:

// Setup view -> viewModel relationship to support value-view.htm and value-vm.ts
ViewLocator.prototype.convertOriginToViewUrl = (origin) => {
    let moduleId = origin.moduleId;

    // remove the file extension
    //moduleId = moduleId.substring(0, moduleId.lastIndexOf('.'));

    // see if the module ends in 'Vm'
    if (moduleId.endsWith('-vm')) {
        var coreName = moduleId.substring(0, moduleId.length - 3);
        return coreName + '-view.html';
    }
    else {
        return moduleId + '.html';
    }
};

I ran this in the main.ts between the call to aurelia.use and aurelia.start.

[EisenbergEffect]

Can you describer what was going wrong? I don't think anything changed there...

[Vaccano]

@EisenbergEffect I just added some detail to my original report.

But the gist is that it passes in an origin.moduleId that was the path + filename + extension. Now it is just filename.

I need that path to be able to tell the loader where the file is.

If not when I try to load src/app.ts, it looks for app.ts (on the root).

[Vaccano]

To make sure I was not crazy, I loaded up another app I have that I had not upgraded recently (it is running aurelia-templating-binding@1.0.0-beta.1.0.2. In that instance origin.moduleId is:

• http://221-schaffs.aruplab.net/TypeScriptHTMLApp2/src/views/app/app.ts

In my version that I have updated to the latest, origin.moduleId is:

• app

I don't really need the extenstion, but I need the path. Or else it looks for app.ts at http://221-schaffs.aruplab.net/TypeScriptHTMLApp2/app.ts (instead of the extra folders of src/views/app/app.ts)

[EisenbergEffect]

You may have an old version of system.js Try running jspm dl-loader --latest and see if that solves it for you.

[Vaccano]

@EisenbergEffect I went to the gutter chat with this issue first. I was advised to do that and it had no effect on the issue.

I also downgraded jspm to 0.16.15. I deleted my jspm_packages and ran jspm install. I also deleted my map section of my config.js

None of it helped.

I am open to other ideas...

[EisenbergEffect]

I don't know of anything we changed in our code that would cause this change, except that we switch from using SystemJS's normalizeSync api to using its normalize api. My understand is that the only difference between those is sync vs. async. Also, normalizeSync is no longer supported. I can't think of anything else that would cause this...certainly nothing in our code as we haven't changed how this is handled in many months. Maybe @guybedford can shed some light on anything in SystemJS that may have changed.

[EisenbergEffect]

You are using the hook correctly. It should work. There's something else going on here. I'm not sure it's in our code. It could be related to the normalization apis of SystemJS having different behavior...or even changing across versions. Worse case...you can always configure what should be prepended to a custom view url. Not ideal, but it would work. We need to hear from Guy and see if something changed in this area.

[guybedford]

@EisenbergEffect the output of normalize in SystemJS is always a full URL with the extension. If @Vaccano is getting app as the moduleId returned, that is not a possible output value of System.normalize, so I don't think it would be in that implementation?

[EisenbergEffect]

I think I know what might be causing this. I was confused because of the version numbers referenced and it being reported on this repo. I think I can get this fixed pretty quickly.

[Vaccano]

@EisenbergEffect I looked at this a bit more and the problem seems to be in aurelia-loader-default.js in the DefaultLoader.prototype.loadModule method. The beta.1.0.1 version had the synchronous call to System.normalizeSync.

But beta.1.1.1 does not have a call to System.normalize in there.

I tried to debug through it, but I am very confused by this file. Most of the methods are defined twice (ie there are two loadModules, two applyPluginToUrl etc.). Almost looks like a bad merge. But it could also be that I am too new to JavaScript to figure out what is going on.

Unfortunately I had to rollback to continue working....

[EisenbergEffect]

That's exactly the bug I was thinking of. I can get it fixed soon.

There methods are defined twice because we support not only system.js but also require.js and dojo. So some methods have alternate implementations based on what loader is available at runtime.