Lazy loaded styles are never hashed

[maosmurf]

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

$ 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

MacOS 10.14 Mojave

Repro steps

my-app/angular.json -> projects/my-apparchitect/build:

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

Then run:

$ ng build --prod

Example in: https://github.com/maosmurf/ng-demo/tree/lazy-styles

The log given by the failure

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

[clydin]

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.

[maosmurf]

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 👍

[jc-1234]

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.

[mehmet-erim]

You create lazy-loadable hashed styles with Webpack.
See my article about this:
https://volosoft.com/blog/Extracting-and-Hashing-Lazy-Loaded-CSS-in-Angular

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);

4. 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.

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

Run the ng build --prod to see the hash

[vlodko]

@maosmurf have you found any workarounds?

[crhistianramirez]

Our workaround for this was to create a post-build script. Here's some code that anyone is free to use, you may need to modify sourceDir. It outputs a manifest.json to the root directory so that you are able to reference your hashed filename by filename in your app at runtime.

We also used hasha for the actual hashing.

const hasha = require('hasha')
const fs = require('fs')

let manifest = {}

const sourceDir = './dist'
fs.readdirSync(sourceDir)
  .filter((filename) => filename.endsWith('.css'))
  .forEach((filename) => {
    const hash = hasha.fromFileSync(`${sourceDir}/${filename}`).substring(0, 10) // unique enough for our cache busting purposes

    const withoutExtension = filename.slice(0, -4)
    const hashedFileName = `${withoutExtension}.${hash}.css`
    fs.renameSync(`${sourceDir}/${filename}`, `${sourceDir}/${hashedFileName}`)
    manifest[filename] = hashedFileName
  })

fs.writeFileSync(
  `${sourceDir}/manifest.json`,
  JSON.stringify(manifest, null, 4)
)

[bogacg]

@mehmet-erim your method seems interesting. Does webpack also minify / prefix styles added this way or we have to provide a css file minified/prefixed beforehand?

[mehmet-erim]

@bogacg Obviously I have not checked this. I have provided minified CSS files.

[poddarkhushbu07]

This feature is quite helpful because I want to refer this lazy loaded files within the application code. So, if this lazy loaded styles are hashed it would not be possible to refer these files within application code.

Can't we have any possible workaround if we want to access hashed file styles file from application code?

Case:
style files which are loaded (lazily and non lazily) both needs to referenced from service.

[mdarefull]

I would also like to comment in favour of this feature.

On one hand, we all know how important fast load time is for Web Apps, that's the main motivation of lazy loading modules in Angular.

The problem is that if I reference big UI libraries, like Angular Material or even a specific component, it is a pain to lazy load those styles so I have to include +1Mb of content as part of my main module.

Manually hashing the file is not desired as a simple npm update could change the content and no one might remember to update the hash.
If a post-build task is possible then why don't we include the hashing as default?

is body-enabled so we could reference them inside any component. Why not to specify a component property inside the style object that tells the builder which component will reference the link and then it is added just as it adds to index.html...

[clydin]

The Angular material themes ideally should not be used within component styles. They are recommended to be placed in a global stylesheet via the project's styles option or directly in the index.html via a link element as a project asset. For additional information, please see https://material.angular.io/guide/theming#using-a-pre-built-theme
One of the added benefits of using a global style is that Angular 11 also provides the new inlineCritical style optimization which will analyze all global styles, inline critical CSS within the HTML and then lazy load the remainder of the global styles.

[mdarefull]

@clydin I think that's an oversimplification of styles management.

First, most complex app won't use pre-built theme, but custom themes, either by creating their own or by customizing the pre-built ones.
In addition you usually also add customizations for components that you don't want to duplicated on every angular component that uses it, like different colors, margins, sizes for tabs, list items, etc.

Where would you put those? If you import the styles in your global stylesheet you are still downloading several Kbs of styles that you don't use to bootstrap the app... if you add customizations to styles.scss to make them global, same thing...
The solution here would be to leverage lazy loading styles just the same way we leverage lazy loading modules... perhaps we could even have a concept of module styles... that is similar to the global styles.scss in capabilities... but is only included when the module is loaded.

Currently, my main module bundle is sitting at 1.22Mb after optimizations, and around 30-40% of it are styles imported in the styles.scss file