Asset revisioning (long-term caching)

[exoszajzbuk]

I'd like to know if it'd be possible to add asset revisioning feature with angular-cli@webpack. As far as I see chunk hashes are only added to .js files during --prod build and are used in the generated index.html

I can think of two possible approaches:

1. The rewrite approach, e.g. https://github.com/smysnk/gulp-rev-all which parses the asset references (considering dependencies) than does re-writing in raw asset files. This would not require using custom helpers in templates/styles.
2. The manifest approach, e.g. https://github.com/nickjj/manifest-revision-webpack-plugin which will populate a manifest file with raw => revisioned mapping. Using helpers in templates/styles could be used for determining the right asset to use.

---

angular-cli: 1.0.0-beta.11-webpack.2
node: 6.2.2
os: darwin x64

[filipesilva]

I'm interested in the discussion around this, but have to say it is not a high priority at the moment.

[mbriggs]

I have been bypassing rails crappy asset pipeline in favour of a js build pipeline for several years now. With the manifest approach, that is typically about 20 lines of code. Feel that would be the case for most server side web frameworks, but given that is a secondary use case, maybe have different build outputs based off of flags? something like ng build -prod -manifest or something like that wouldnt generate index.html, instead just giving hashed filename js output and a manifest.json.

I feel like control over whether or not hashing is done to file names is actually an orthogonal issue to adding json manifests. Elixir Phoenix is an example of a framework with decoupled hashing, to integrate with it you want to output your minified assets to a convention based directory, and then run a digest build task built into the framework. It would be great to have more fine grained support for both things in angular-cli

[Bnaya]

I think its a very important feature
typescript + a2 AOT helps you find alot of possible runtime errors on build time, and using webpack file-loader will cache possible 404 errors for assets and will add alot of flexibility for how to bundle your static files (very useful for other platforms)

[laurentgoudet]

Asset revisioning has been a best practice for years and is a requirement for most production applications - it's sad that the angular-cli still doesn't have a proper production workflow.

One thing to note with the manifest approach is that it does not scale on the front end, as you'll need to load an ever-growing json map of hashed filenames. In addition, it'd be fairly hacky to dynamically rewrite AoT-generated NgFactories on the backend, assuming you have a backend, so the best approach is probably the rewrite one. Plus yeah an awesome side-effect of the rewrite approach is checking for 404, which makes refactoring / cleaning-up your assets folder a lot easier (and can even be automated, e.g. detect unused asset files).

[MartinMa]

The html loader module for webpack can do this. I'm using it in an Angular 4 + webpack 3 project (not angular-cli base though).

This is a snippet from my webpack config:

{
  test: /\.html$/,
  use: 'html-loader?interpolate'
},
{
  test: /\.(png|jpe?g|gif|svg|woff|woff2|ttf|eot|ico)(\?v=[0-9]\.[0-9]\.[0-9])?$/,
  use: 'file-loader?name=assets/[name].[hash].[ext]'
},

The file-loader copies all referenced/required assets to the assets/ subfolder, extending the filename with the hash of the file. The html-loader processes the html files (templates) and requires all image urls in img src attributes like this one <img src="image.png"> and changing the attribute with the new hash-extended version (at least, that's what I think it does).

However there's one problem. This approach doesn't play well with AoT compilation, because the html-loader doesn't seem to be part of the AoT compilation pipeline. I'm not that experienced in webpack. Maybe someone has an idea?

UPDATE It seems, the html-loader has been removed from this project on purpose (see fix(build): remove html-loader) So this is maybe not an option.