angular-cli: ng build --prod is not creating unique hashes

I think you’re having some weird errors and can’t debug it, and so, understandably, you’re frustrated. But this is a tracker for bugs and feature requests. If we can we also try to help with support requests. We’re very lucky to have awesome community members that also spend time trying to help people here in the issue tracker.

But we can’t really help much at all if you don’t fill in the issue template. I read your issue and have no idea what’s going wrong and how to help you. And when other users search the issue tracker and see your issue, it also doesn’t help them.

So I think the best thing to do is to close this issue, and ask you to open a new one. In that new one please fill in the issue template and give us an idea of what’s happening and how to reproduce it. That way we’ll have a chance to help you.

Closing as it looks like the issue has been solved with the answers above.

This is still an issue with 6.0.1

I’m not sure what’s happening on your VSTS build server and personally don’t have one to investigate myself. Without being able to reproduce myself there just isn’t much I can do.

On your local machine though, you say it changes so it does sound like it’s related to the build server environment. If you can get me a reproduction that I can run on my machine and see this I am happy to investigate, but without one there isn’t much hope of fixing the problem.

I can say that we don’t do anything special with hashes though. If you can’t provide me with a reproduction that doesn’t need a specific server, maybe you can try to setup a simple reproduction with just webpack and see if the problem manifests on your server as well, then submit an issue on the webpack repo.

In the 6 months since I reopened this issue there still doesn’t seem to be a reproduction that shows there’s a problem with how Angular CLI produces unique hashes for bundles.

There’s been a some very informative comments on this issue that point towards how servers and browsers interpret cache requests, like https://github.com/angular/angular-cli/issues/10641#issuecomment-491588141, https://github.com/angular/angular-cli/issues/10641#issuecomment-492714699, and https://github.com/angular/angular-cli/issues/10641#issuecomment-517290830. If you’re still seeing cache related problems, I suggest you read through these comments to see if your setup is similar.

I will again close this issue as it’s not actionable on Angular CLI. If you see it happening on your specific environment, help us by providing exact steps that we can follow on our machines to see the problem. If it happens on your CI but not on your local machine, you might have to figure out what’s different between the two.

I have facing the same issue since the hash do not change the browser does not load the changes in the page as it continues using cached version. Angular CLI: 1.7.4 Node: 8.11.3 Angular: 5.2.7

@rajaramtt try setting meta tags to your HTML, set Max age to 0, no cache. Say if the above approach didn’t work, Try setting the cache control headers to ‘no cache’ headers in your Apache or IIS server 2. If you are using https configured url, it sets max-age to 0 by default

I’m also seeing the same issue - the hashes are there but the same every time.

VSTS clears EVERYTHING between every build because the build server is a shared resource.

So you should be able to test this by simply whipping everything including all caches for angular/webpack every single time you do a build. It appears that it restarts whatever randomizer is being used and it starts at the first number again resulting in identical hashes.

i think in some scenario header no cache may not help. something like

1. user open module1
2. you edit module2 and deploy (may be a hotfix)
3. user go to module2 in this case angular will try to load module2 from old hash too. for me this happen because user open browser and do something then sleep notebook without close browser. and use it again in tomorrow, sometime user use versions that release 7 days ago.

in this case you may set your web server to redirect not found js to some js like reload.js that force page when it reference file that not exists anymore. like: https://gist.github.com/mix5003/0aff8719804494530790276406499e8c (this un-tested config. use on your own risk) or just create you own error handler and add this to check errors.

if (err.message) {
  if (err.message.indexOf('Error: Loading chunk') !== -1) {
    // TODO: be more user friendly
    location.reload(true);
    return;
  }
}

but i still don’t know if user open module1 and i want to push hotfix to module1, how to do it. for now i put build date to environments.ts and force angular send it every request and check it at server side to tell client to force reload in serious case. is this way ok? or someone has a better way?

@filipesilva any updates or idea on this issue, this still exists with angular 7x

@alan-agius4 it was not solved. I am having the same issue with Angular CLI: 6.1.3

Greeting, I face the same issue. I need to re-product the project to see the changes in cloud. Does anyone solve this issue?

Just reporting back. I haven’t been able to recreate this locally, but it’s happened a few times in the past. I created a project and test script to rerun builds.

The test script waits for the user to make a code change, then given the go-ahead, recompiles with AOT and diffs all the JS/CSS files with the previous run. If the file name is somehow the same, but the contents are different, it blows up.

I haven’t been able to recreate locally with various trials, such as 2 lazy loaded modules depending on a 3rd local dependency, changing only styles, changing only html, etc.

So, instead for our CI build, I wrote a different script that does a similar test. It retrieves the last stable version of the build and does the filename match diff check. If the filenames are the same, but the contents are different, it will blow up. This should at least give me insight into when this occurs or what kind of commit causes it.

If anyone wants a template for that script, it looks like this:

mkdir -p .tmp/last-stable-build
tar -xf .tmp/last-stable-build.tar.gz --directory .tmp/last-stable-build
# Default hashes are 20 character hex
# https://webpack.js.org/configuration/output/#outputhashdigest
# https://webpack.js.org/configuration/output/#outputhashdigestlength
files=$(cd .tmp/last-stable-build && find . -regextype posix-extended -regex ".*[a-f0-9]{20}\.(js|css)")
for i in $files; do
    if [ -f "dist/build/$i" ]; then
        # diff returns a non-standard 0 code when differences are found
        # anything other than 0 will cause our build to fail
        diff -q .tmp/last-stable-build/$i dist/build/$i
    fi
done

I can reopen, but I will reiterate: if we don’t have a reproduction that we can follow, we cannot investigate the issue. I haven’t yet seen a report that provides anything that I can follow and get the same result as described in this issue.

So please, if you would like this to get fixed, and see it happening on your specific environment, help us by providing exact steps that we can follow on our machines to see the problem. If it happens on your CI but not on your local machine, you might have to figure out what’s different between the two.

@angular/cli: "7.0.6"
@angular/core: "7.0.4"
typescript: "3.1.6"

ng build --prod generates files without hashes AND with sourcemaps and I have this in angular.json:

          "configurations": {
            "production": {
              "fileReplacements": [
                {
                  "replace": "projects/my-app/src/environments/environment.ts",
                  "with": "projects/my-app/src/environments/environment.prod.ts"
                }
              ],
              "optimization": true,
              "outputHashing": "all",
              "sourceMap": false,
              "extractCss": true,
              "namedChunks": false,
              "aot": true,
              "extractLicenses": true,
              "vendorChunk": false,
              "buildOptimizer": true,
              "budgets": [
                {
                  "type": "initial",
                  "maximumWarning": "2mb",
                  "maximumError": "5mb"
                }
              ]
            }
          }

in package-lock.json I see that webpack version is 4.19.1 (not sure if it matters)

EDIT: I feel like such a newbie 😃 I was running npm run build --prod thinking I am running ng build --prod. I’m not going to delete the comment, maybe someone else does the same and finds this. Of course, actually running ng build --prod works fine (or npm run build -- --prod, either way)

Ok that is odd, we test for that in https://github.com/angular/devkit/blob/master/packages/angular_devkit/build_angular/test/browser/output-hashing_spec_large.ts.

I did a simple test right now by adding console.log('hello') to main.ts and I do see the hash changing:

kamik@RED-X1C6 MINGW64 /d/sandbox/latest-project (master)
$ ng build --prod

Date: 2018-05-04T19:37:41.519Z
Hash: f25fd6788a4969c52b70
Time: 13076ms
chunk {0} runtime.6afe30102d8fe7337431.js (runtime) 1.05 kB [entry] [rendered]
chunk {1} styles.34c57ab7888ec1573f9c.css (styles) 0 bytes [initial] [rendered]
chunk {2} polyfills.6c08419970f9e4781b69.js (polyfills) 59.4 kB [initial] [rendered]
chunk {3} main.5c2aab6a636f72a9a865.js (main) 153 kB [initial] [rendered]

kamik@RED-X1C6 MINGW64 /d/sandbox/latest-project (master)
$ ng build --prod

Date: 2018-05-04T19:38:07.685Z
Hash: 41d53ef1d6943f2cd0e2
Time: 9482ms
chunk {0} runtime.6afe30102d8fe7337431.js (runtime) 1.05 kB [entry] [rendered]
chunk {1} styles.34c57ab7888ec1573f9c.css (styles) 0 bytes [initial] [rendered]
chunk {2} polyfills.6c08419970f9e4781b69.js (polyfills) 59.4 kB [initial] [rendered]
chunk {3} main.2f847dc2015268319a27.js (main) 153 kB [initial] [rendered]

You example mentions adding a lazy route though. Can you be more specific? I don’t know how you’re adding it, and small differences in how you do it can have different behaviours.

Can you make a simple repro where you see this happening and upload it to github? Ideally I would be able to clone it, checkout a commit, ng build --prod, then checkout the another commit with changes, ng build --prod and see no hash change.

Still exists, Please provide an alternative solution.

@rajaramtt the most recent updates are in the comments directly above yours.

I got the same issue, ng build --prod generates the same hashed file names even if the code is different. In the log, I see the hash is different but the name of the files is the same.

Maybe something wrong with webpack.

@trichetriche Please ensure that the project’s production configuration is configured appropriately. A new project will contain the following:

          "configurations": {
            "production": {
              "fileReplacements": [
                {
                  "replace": "src/environments/environment.ts",
                  "with": "src/environments/environment.prod.ts"
                }
              ],
              "optimization": true,
              "outputHashing": "all",
              "sourceMap": false,
              "extractCss": true,
              "namedChunks": false,
              "aot": true,
              "extractLicenses": true,
              "vendorChunk": false,
              "buildOptimizer": true
            }
          }

Ok, well it definitely isn’t working right because I can make changes and it still isn’t updating the hashes. We’re getting constant complaints from people about bugs we’ve already fixed and telling them to clear their cache is fixing it. I have yet to see even one file change it’s hash build to build event with changes.