Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Subresource integrity / filename hash inconsistency
See original GitHub issueVersions
Angular CLI: 1.6.3
Node: 9.3.0
OS: darwin x64
Angular: 5.2.0
... animations, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... platform-server, router
@angular/cli: 1.6.3
@angular-devkit/build-optimizer: 0.0.36
@angular-devkit/core: 0.0.22
@angular-devkit/schematics: 0.0.42
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.9.3
@schematics/angular: 0.1.11
@schematics/schematics: 0.0.11
typescript: 2.5.3
webpack-bundle-analyzer: 2.9.2
webpack: 3.10.0
AND
Angular CLI: 1.6.4
Node: 9.3.0
OS: darwin x64
Angular: 5.2.0
... animations, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... platform-server, router
@angular/cli: 1.6.4
@angular-devkit/build-optimizer: 0.0.38
@angular-devkit/core: 0.0.25
@angular-devkit/schematics: 0.0.48
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.9.4
@schematics/angular: 0.1.13
@schematics/schematics: 0.0.13
typescript: 2.5.3
webpack-bundle-analyzer: 2.9.2
webpack: 3.10.0
Repro steps
I don’t have a minimal reproduction, but here is a gist to two yarn lockfiles: https://gist.github.com/karptonite/925a56d957a34ff65063d52e619f7fcc
Observed behavior
when building with --prod --subresource-integrity:
The subresource integrity SHA hash can change without the hashed filename changing as dependencies are updated.
In the two yarn lockfiles shown, nothing that is included in polyfills changed, and the hashed filename (--output-hashing all, since --prod is set) remains unchanged between builds. However, because some other dependencies were updated (notably, the uglify version changed), the integrity SHA hash changed. That is a problem because our js is served by a CDN, which assumes that if the filename remains unchanged, it can continue to serve from the cache.
Desired behavior
When anything that can affect the content of the minimized file changes, that should change the filename hash. This could be accomplished by naming the file based on the minimized code, but it could also be as simple as hashing in the version numbers of the relevant packages involved in minimizing the code when generating the filenames.
If you are unable to reproduce this, let me know, and I’ll see if I can figure out how to reproduce it. I got stuck (working in a minimal project) trying to force yarn to downgrade the version of uglify to match what is in my production yarn lock above.
Issue Analytics
- State:
- Created 6 years ago
- Reactions:9
- Comments:27 (4 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
can we get this fixed soon? I know it’s “inconvenient” and we can clear the cloudflare cache when it happens but… when doing daily deploys with about 100 different domains it’s getting past the point of “inconvenient” and more like a royal pain in the ass. o yeah then there is the whole issues of telling everyone to clear their cache because their browser is caching the files for a year.
Ahh I just saw the contenthash is already being used, I inferred it can’t be since the hashes were the same …
At least I’ll share data to reproduce below, maybe someone can see what I’m missing
index.html no caching *.js 7 days caching
cached runtime
actual runtime
in actual index.html
sha384 sums: cached: VDinAQO6iY5043Owfl98myR/zDHxFa9Q0jmbWqE1YxjijsC49QdU2tDIw0775Biw base64: actual: gyhzYjNbRNkm0kVr49UbYE+nlkhh8oeH2mMogqSClQCO/fgki/miELyW/YJhdIri
for some reason, they both don’t match the integrity hash from the index.html
Chrome 76 output: