Angular-cli: Lazy loaded styles are never hashed

Created on 11 Oct 2018  ·  5Comments  ·  Source: angular/angular-cli

We are great fans of lazy-css functionality in ng build, it allows us to serve several apps from one code-base, as we add app1.css ... appN.css depending on the request, using angular universal.
Given our high-traffic page we use a CDN and therefore rely on changing hashes for changed CSS, as we otherwise would have to manage CSS cache invalidation manually.

How can we have hashed lazy CSS back?

See also #11235 and #11704

Bug Report or Feature Request (mark with an x)

- [x] bug report -> please search issues before submitting
- [ ] feature request

Command (mark with an x)

- [x] build

Versions

$ node --version
v8.11.4
$ npm --version
5.10.0



md5-e544c1564fdd2417018eb10fdcceab90



$ ng --version

     _                      _                 ____ _     ___
    / \   _ __   __ _ _   _| | __ _ _ __     / ___| |   |_ _|
   / △ \ | '_ \ / _` | | | | |/ _` | '__|   | |   | |    | |
  / ___ \| | | | (_| | |_| | | (_| | |      | |___| |___ | |
 /_/   \_\_| |_|\__, |\__,_|_|\__,_|_|       \____|_____|___|
                |___/


Angular CLI: 6.2.4
Node: 8.11.4
OS: darwin x64
Angular: 6.1.2
... animations, common, compiler, compiler-cli, core, http
... platform-browser, platform-browser-dynamic, platform-server
... router, service-worker

Package                            Version
------------------------------------------------------------
@angular-devkit/architect          0.0.0
@angular-devkit/architect-cli      0.0.0
@angular-devkit/build-angular      0.0.0
@angular-devkit/build-ng-packagr   0.0.0
@angular-devkit/build-optimizer    0.0.0
@angular-devkit/build-webpack      0.0.0
@angular-devkit/core               0.0.0
@angular-devkit/schematics         0.0.0
@angular-devkit/schematics-cli     0.0.0
@angular/cdk                       6.4.5
@angular/cli                       0.0.0
@angular/material                  6.4.5
@angular/pwa                       0.0.0
@ngtools/json-schema               1.1.0
@ngtools/webpack                   0.0.0
@schematics/angular                0.0.0
@schematics/schematics             0.0.0
@schematics/update                 0.0.0
ng-packagr                         4.1.0
rxjs                               6.2.2
typescript                         2.9.2
webpack                            4.16.4



md5-1654f7cb7fb0a916121922f1f224c8fa



{
  "input": "src/extra.css",
  "lazy": true,
  "bundleName": "extra"
}



md5-cb88aa1f1d6a1c087e74a58829a1d9c3



$ ng build --prod



md5-e3a043f6d4f65dc2d44297107d3696cb



chunk {4} extra.css (extra) 0 bytes [initial] [rendered]

Desired functionality

extra.123456678.css instead of extra.css, as it was until recently.

While removing the hash from lazy styles helps with lazy includes, it hinders cache invalidation.

Our use-case:
We render the app (kurier.at) and have lazy styles. Given we use angular universal, we have no problem checking /dist for the current css hash file.
After deploying a new version, the new css (with changed hash) is included, yet the old CSS remains valid on CDN (cloudflare) - so there are 2 benefits fron this:
1) no need for invalidating style.css
2) old CSS remains valid for old cached pages.

How can we get the old functionality back? Currently, our only option for upgrading to ng6 would be to manually add hashes after ng build --prod

devkibuild-angular feature

Most helpful comment

Thank you for the feedback.

This is intentional

I fully understand the motivation for the recent changes, yet the backwards-incompatible changes caused some headache.

it could do so with a post build step.

Done.

I'm going to mark this as a feature request.

Would be great to have old functionality back using already provided tools (without the need of manual post-build step), so thank you for that 👍

All 5 comments

This is intentional, lazy loaded styles are not referenced by the built application automatically and are only intended to be referenced by the developer. As such, a hash prevents the file from being deterministically referenced as the name would change upon every content change.

In addition, since the file is not referenced automatically within the application, the filename can be modified as necessary after the build. So as mentioned, if the project wanted a hash or some other unique identifier attached, it could do so with a post build step.

There is the potential for an additional capability in regards to either allowing template tags in bundleName or adding an additional option to enable hashing on a per file basis. I'm going to mark this as a feature request.

Thank you for the feedback.

This is intentional

I fully understand the motivation for the recent changes, yet the backwards-incompatible changes caused some headache.

it could do so with a post build step.

Done.

I'm going to mark this as a feature request.

Would be great to have old functionality back using already provided tools (without the need of manual post-build step), so thank you for that 👍

We are running into similar issue with invalidating lazy loaded stylsheets. Would be great if there can be a config setting in angular.json to turn this on or off.

You create lazy-loadable hashed styles with Webpack.

My Angular CLI version: 8.3.19

  1. ng new lazy-load-css --style css
  2. Open the angular.json and remove styles.css from styles array.
  3. Create style-loader.js in the src folder and then replace with the following code:
import styles from './styles.css';
const node = document.createElement('style');
node.textContent = styles;
document.querySelector('head').appendChild(node);
  1. Add the ngOnInit method in the AppComponent like below:
  ngOnInit() {
    setTimeout(() => {
      import('src/style-loader');
    }, 1500);
  }

See Webpack import() function. Also you can see Webpack magic comments for chunk naming, etc.

  1. Add a style to styles.css to see changes. I added the background color style.
  2. Run the app

lazy-loadable-css-hashing

Run the ng build --prod to see the hash

@maosmurf have you found any workarounds?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

JanStureNielsen picture JanStureNielsen  ·  3Comments

gotschmarcel picture gotschmarcel  ·  3Comments

donaldallen picture donaldallen  ·  3Comments

jmurphzyo picture jmurphzyo  ·  3Comments

brtnshrdr picture brtnshrdr  ·  3Comments