Images in templates are not fingerprinted

[texel]

OS?

Mac OS X

Versions.angular-cli: 1.0.0-beta.21

node: 6.9.1
os: darwin x64

Repro steps.

Due to the way that assets are built, references to images in html templates are not processed by webpack and therefore aren't fingerprinted. Furthermore, the src attributes don't get prefixed by publicPath (in the event that the PR #3285 is merged) and we don't have the flexibility to locate images with their components (#3292)

The log given by the failure.

n/a

Mention any other details that might be useful.

I have a branch that uses html-loader instead of raw-loader for html files, which fixes all these problems. I'd be willing to create a PR that makes this change, perhaps only if passed a config option, but I'm open to other ideas and would like to get the opinion of the angular-cli team as to whether this is something they're interested in supporting.

[hansl]

The problem is that html-loader is not Angular2 friendly. It messes up the paths and doesn't understand the templates. We're looking at it but had to remove it (see #2537 and all related issues). We need more investigation.

[hansl]

Oh and for reference, the assets path being wrong is webpack-contrib/html-loader#85.

[texel]

@hansl I'm not sure what you mean by messing up paths? You can get html-loader to play nicely with Angular 2 by passing it a -minimize flag, I have it working just fine in a non-angular-cli app, and I've hacked in support for it in our custom angular-cli branch. It supports the current use of the assets folder by prefixing with ~, so <img src="~assets/images/foo.png"> will be interpreted as require('assets/images/foo.png') while <img src="assets/images/foo.png"> will be interpreted as require('./assets/images/foo.png').

I'm a bit confused though, what was the issue with base href exactly?

[clydin]

The change would essentially break all existing projects that use img tags. The use of the ~ is also webpack specific so institutionalizing its use would break down the CLI's abstraction around webpack.

Looking at the documentation, the html-loader does seem to have a setting named root, which could be set to the project root and allow root-relative URLs to be used instead of the ~. Whether that is better or not is up to question (e.g., confusion with regards to base href usage). Also, its viability would need to be tested of course; and it would still be a breaking change.

[texel]

@clydin At first it should probably be opt-in, though I'd love to find a way to make it backwards compatible with existing projects. To your point yes, ~ is webpack-specific but it's something that already works in CSS @import statements: @import "~assets/stylesheets/variables.scss";.

It seems like there's a bit of a philosophical split here with regard to how assets are resolved- in most cases (TypeScript files, CSS, etc) they're hooked into the Webpack system and resolved on-disk at compile time, but in templates they're referred to by relative path.

For what it's worth, at my company we serve all our assets (JS and otherwise) from a CDN, and only serve the template from our primary domain. By setting publicPath in Webpack, our configuration works out of the box in both development and prod, plus we get fingerprinting (and even inlining if we want) of our images for free.

The only way to support this use case with the current incarnation of angular-cli is to manually prefix every src attribute with our CDN URL which is a non-starter. I suppose we could write a build task that does string replacement on the built artifacts but that still doesn't get us 1) cache busting and 2) the ability to refer to images outside the assets folder.

I'm open to other ways of solving this problem and I'm certainly sensitive to the backward-compatibility concerns. Perhaps a custom html loader that processes paths differently, eg src="assets/images/foo.png" is the equivalent of require('assets/images/foo.png') and src="./images/foo.png" is equivalent of require('./images/foo.png')?

[clydin]

@texel, I agree as to the value it would provide. Implementing it with minimal upheaval is the problem.

As to the use of the tilde, yes it currently works in other areas (as do several other webpack/webpack-plugin related capabilities), but they are currently not (at least to my knowledge) documented as supported or recommended features of the CLI. Personally, I view them no different than internal APIs: They work but expect them to break in the future.

[jupapios]

are there any updates on this issue?

[donovankim]

+1

[balteo]

Any update on this issue? Also see #4212

[filipesilva]

We had this in once, by using HTML-loader, but it broke a lot of projects (see #2396).