ng test gives 404 from assets files

[tarlepp]

OS?

Linux Ubuntu 16.04

Versions.

angular-cli: 1.0.0-beta.17
node: 6.7.0
os: linux x64

Repro steps.

My 'About' component uses images from assets, and ng test shows me following warnings;

20 10 2016 19:15:52.452:WARN [web-server]: 404: /assets/angular.png
20 10 2016 19:15:52.453:WARN [web-server]: 404: /assets/firebase.png

[filipesilva]

It's a bug, will fix.

[Meligy]

Same issue here.

Observation:

The path is going from the port where karma is running. The generated path is something like /assets/my-image.png, but when this is opened in karma, that's relative to, say http://localhost:9876, http://localhost:4200/ (which is not running with just ng test anyway).

Analysis:

This was happening even though the path of the image bin the component was relative to the component file, which means that the path translation is working fine. It's serving the files that is the issue.

Question:

Is it possible to serve assets in the same host:part as karma is running?

Seems like the way to go (ignoring base-href fun for now), but not sure if Karma supports that.

[ZenabKhan]

Hello, is there a workaround for this until the bug is fixed?

[roupify]

+1

[Meligy]

Yes, there is a workaround!

In the karma configuration karma.conf.js, you can do the following:

var angularCliConfig = require('./angular-cli.json');

var files = [
  { pattern: './src/test.ts', watched: false },
];
var proxies = {};

var assets = angularCliConfig.apps[0].assets;
for (var i = 0; i < assets.length; i++) {
  var asset = assets[i];
  proxies['/' + asset] = '/base/src/' + asset;
  files.push({
    pattern: './src/' + asset,
    included: false,
    served: true,
    watched: true,
  });
}

Then set the files, and proxies properties on the config object.

module.exports = function (config) {
  config.set({
    ...
    files: files,
    proxies: proxies,
    ...
  });
};

I was looking at @filipesilva's PR #3543 and learned from it that Angular CLI modifies the karma config internally as well, which means that it might be possible to fix this issue using the the snippet I posted now injected by the CLI just like the other PR, but I haven't had time to look at it yet. Maybe next week.