feat(build): add ability to disable webpack's cache busting mechanism

[aegyed91]

Optionally disable webpack's caching mechanism with the -dcb flag.

Usecase: You want to solve cache busting of the generated bundles with a different strategy.

closes #3853

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

---

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If you signed the CLA as a corporation, please let us know the company's name.

[aegyed91]

I signed it!

[googlebot]

CLAs look good, thanks!

[clydin]

I have an almost done PR (needs tests) that will allow finer control over the file hashing and that will cover your issue as well as another open issue regarding hashes on Dev builds.

[filipesilva]

@tsm91 this PR looks like what I imagined it to be.

Could you change the option name to --cache-bust and default it to true instead of having a negation in the name? This is because all options can also be negated by adding no at the end e.g. --no-cache-bust.

A test is also needed. See https://github.com/angular/angular-cli/blob/master/tests/e2e/tests/build/chunk-hash.ts for the current one.

@clydin your solution sounds interesting but lets discuss it in the #3853 instead.

[clydin]

What I mentioned in that issue is different than the PR I mentioned above. I'll put out a WIP today. Instead of a Boolean option it allows three options: none; build (for a build unique hash); content (hash based on content). It also handles the file and URL loaders.

[aegyed91]

I think 99% of the case people will either want to entrust webpack with cache busting or not. A simple toggle flag is more suitable.

It also handles the file and URL loaders.

I skipped the part where webpack process image and font files. I did it on purpose, because there is no backend solution for parsing css, finding file references and do cache busting there.

On the other hand i do agree the default hashing behavior of file- and url loader is ugly.

By default the filename of the resulting file is the MD5 hash of the file's contents with the original extension of the required resource.

Which means sky-bg.jpg becomes 8bcfb98e274f484ebac02d81670b7e4c.jpg. This also happens with the serve task (so it is not build task specific), if you tick the --verbose flag you can see.

I also agree it would be a nice feature to allow finer control over the hashing mechanism. But it is not logical to do it with a command line flag.

Something like this i could imagine angular-cli.json excerpt:

{
  "defaults": {
    "cache-bust": {
      "js-filename": "[name].bundle.js",
      "js-chunk-filename": "[name].chunk.js",
      "sourcemap-filename": "[name].bundle.map",
      "css-filename": "[name].bundle.css",
      "file-loader-name": "[name].[ext]",
      "url-loader-name": "[name].[ext]"
    }
  }
}

This way you could configure filename template placeholders for url- and file-loaders and bundle names. This way you have 100% control over cache busting and file naming.

[clydin]

At that point, the config becomes a pseudo-webpack config. The encapsulation is important as webpack could very well be replaced in the future.
The reason for the "build" option is that there is another feature request for performing development builds with a build fingerprint.

I understand why you skipped the asset related loaders but having an option that advertises itself as disabling cache busting but only does it partially is kind of false advertising.

[clydin]

Based on the discussion and described use cases, I adjusted the command option values.
WIP PR is #3885

[aegyed91]

close because i find @clydin 's implementation better: #3885

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}