Angular-cli: ng serve --prod Cannot use [chunkhash] or [contenthash]

[alan-agius4]

Versions

Angular CLI: 6.0.0-rc.5
Node: 8.9.1
OS: win32 x64
Angular: 6.0.0-rc.5
... animations, cli, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, router

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.5.7
@angular-devkit/build-angular     0.5.7
@angular-devkit/build-optimizer   0.5.7
@angular-devkit/core              0.5.7
@angular-devkit/schematics        0.5.7
@ngtools/json-schema              1.2.0
@ngtools/webpack                  6.0.0-rc.5
@schematics/angular               0.5.7
@schematics/update                0.5.7
rxjs                              6.0.0-uncanny-rc.7
typescript                        2.7.2
webpack                           4.5.0

Repro steps

• Set "hmr": true under serve options
• ng serve --prod

Observed behavior

****************************************************************************************

Date: 2018-04-20T11:18:32.210Z
Hash: 479da56e19191460642b
Time: 25039ms
chunk {0} admin-admin-module-ngfactory.2293166986b2fdeaaf9e.js (admin-admin-module-ngfactory) 811 bytes  [rendered]
chunk {1}  (runtime) [entry] [rendered]
chunk {2} styles.34c57ab7888ec1573f9c.css (styles) 0 bytes [initial] [rendered]
chunk {3} polyfills.fbe8aa029ddbd67561f0.js (polyfills) 59.4 kB [initial] [rendered]
chunk {4} main.272e4975a98129fc0e4c.js (main) 382 kB [initial] [rendered]

ERROR in chunk runtime [entry]
[name].[chunkhash:20].js
Cannot use [chunkhash] or [contenthash] for chunk in '[name].[chunkhash:20].js' (use [hash] instead)

Desired behavior

No error

[billdwhite]

I was able to get around this by setting "outputHashing": "none" in my angular.json file. I'm not entirely clear on how that works anyway but it allowed me to keep working until this gets resolved.

[evisong]

I had similar issue but not in a ng project. Upgrading Webpack related devDependencies to latest solve my issue.

[mgechev]

@alan-agius4 still experiencing this problem?

[alan-agius4]

Yes, this is still reproducible with 7.1.2, which is sort of indented since using the chunkhash would break HMR.

There are two possible fixes for this.

1. If using hmr with outputHashing we display an appropiate error that states that these 2 options cannot be used together.
2. If running under HMR, we change the contenthash and chunkhash to hash. in https://github.com/angular/angular-cli/blob/2326850374cd393a825e339beb5846afcff87f8a/packages/angular_devkit/build_angular/src/angular-cli-files/models/webpack-configs/utils.ts#L32-L33

[muuvmuuv]

Any progress? IMO both fixes makes sense, I would use them together. Printing a warning and use [hash] instead.

Current solution for me is:

        "serve": {
          "builder": "@angular-devkit/build-angular:dev-server",
          "options": {
            "browserTarget": "aqua:build",
            // ....
            "hmrWarning": false,
            "hmr": true
          },
          "configurations": {
            "production": {
              "browserTarget": "aqua:build:production",
              "hmr": false // <------
            }
          }
        },

[alvaromartmart]

I'm facing this issue since I updated to Angular v11

[kevinfarrugia]

I have seen this issue on other frameworks using Webpack and webpack-dev-server (when using HMR / --hot) and the most frequently proposed solution is to use a Webpack configuration similar to the below or removing the hash entirely:

filename: `[name]${isDev ? '[hash]' : '[chunkhash:${length}]'}.js`,

chunkhash and contenthash may cause a memory leak. Reference: https://github.com/webpack/webpack-dev-server/issues/377#issuecomment-241258405

[alan-agius4]

@kevinfarrugia, yeah that make sense,
Thanks for sharing.

[alvaromartmart]

Thank you @kevinfarrugia.

So it seems like the best workaround -without needing a custom webpack configuration- is to set outputHashing to none in angular.json

[alan-agius4]

Will be look at landing a fix for this in the coming days.