Angular-cli: No hash in name in production build

[fredrik-holmqvist]

Hi

I am wondering if there is a setting to disable the hash in the name for main bundle and style bundle for production builds?

/Fredrik

[grizzm0]

No there is not.

You could fork the repo and edit ./angular-cli/packages/angular-cli/models/webpack-build-production.ts to remove it if you really want to.

[filipesilva]

^ what @grizzm0 said 💃

[fredrik-holmqvist]

I could fork it but I would rather have the option of specifying this in the angular-cli.json, it seems strange to me to have this as a hardcoded feature

[grizzm0]

angular-cli is built to "just work" with as little options as possible. If you want more complex usage you should probably have your own webpack setup instead.

Imagine the config file if we would accept every single use case.

An addon system is in the plans and has been discussed in #1656.

[fredrik-holmqvist]

Sure, I understand that we can't add settings for everything but when you default to this type of behavior it would be good to at least be able to turn it off. What is the time frame for this addon system? Why not just expose the webpack config directly like you do with karma and protractor?

[grizzm0]

You could say that about anything that is enabled by default. What's the reason you want to disable the hashing for?

[fredrik-holmqvist]

Exactly, but for karma and protractor there is config files, why not webpack? I have nothing against defaults that make it "just work" for most people but it should still be possible to change thing using the configuration.

Our reason it this:
We push the files to a cdn using a inhouse system which we have to use. This system uses a config file where we define the file that should be put there as part of our build. It does not handle wildcards in the filename and because of this we can't use the production build and don't get the tree shaking and everything else.

I guess I have to do a workaround for this but it feels sad that the only options is forking or going the webpack route directly, whats the point of the cli then?

[filipesilva]

@fredrik-holmqvist I understand this is a need you have, but surely you understand that we could not predict that your in-house CDN has a problem with wildcards. The CLI doesn't aim to cover every scenario possible.

If this is a big need for your org I encourage you to make a PR to support such an option, preferably on the build command. Otherwise at the moment I'd say this is one of the lowest priority requests around.

But a workaround here seems much easier than that: have a script that globs your files in dist/ after a prod build, renames them to remove the hash, and does the same in index.html.

[fredrik-holmqvist]

It's not an in-house CDN and it's not that it doesn't support wildcards. It's the way we version, we want it to be predictable so that teams can upgrade to a new version in a predictable way, without having to know any hashes, more like you version libraries on CDNs. And for this we would have liked for it to not touch the names of the files when you do a production build, but I get it, we are not really the core audience for this tool, to much custom stuff unfortunately

We have already made a workaround for this so this issues is resolved from our side

[filipesilva]

@fredrik-holmqvist I've received another request for this, and tbh I think I closed this too soon. If more people want this, they wouldn't find the issue, nor work a PR to add it.

[chouclee]

Same request, my use case is server side rendering. I need to replace several variables in html string (preferably, just like React way).

<script>
    window.__INITIAL_STATE__ = ${JSON.stringify(initialState)}
</script>

But cli pushed some unpredictable hashes into index.html so the option left to me is to use that index.html rather than html string. It's kind of hacky 'cause I need to read the html file and replace the strings. It would be much easier/faster to hard code if we can.

[filipesilva]

Sorry, I forgot to reopen this on my last comment!

[un33k]

How about this:

1. A flag to (enable / disable) hashing
2. An include list - files & wildcards to hash
3. An exclude list - files & wildcards to exclude

The above may include the assets directory as well. (for when hosting on CDN)
The default can be left as whatever behavior we have today.

Those who don't need hashing, simply turn it off.

[un33k]

@grizzm0 One reason not to hash - would be to use an external tool (e.g. gulp plugin) to hash everything, even the images, especially if you are going to host the project on let's say AWS S3/CloudFront.

Now, if NG-CLI took care of all the files (*.png, *.gif, etc.) in the assets directory as well, then one could say angular-cli is built to "just work".

However, as it stands, since there is no non-forky way to disable the hashing, any external hashing tools will create ugly double-hashed names for the .js/.css/.map/.gz files that NG-CLI already hashed. But the images, for example, will have single-hash in their names.

One might say, well that is not a big deal. However, since ng-cli is a community-driven project, we might want to make it work elegantly and for everyone.

Options with default values may be the right approach here.

[mmoravcik]

BTW this is easy to do on your side as a part of the deployment:

$ mv inline.*.bundle.js inline.bundle.js will get rid of the hash

then in your index.html have
<script src="build/js/inline.bundle.js"></script>

+1 to a flag, though

[SSilence]

I would also need this option. I include the js files in a CMS and don't want to update the html snippet every time I make a new release of my angular 2 application.

[kemsky]

The reason we are using angular-cli is that it eliminates configuration process and provides the same workflow for each project. It just does not make sense to repeat all configuration and build steps with webpack or gulp or rollup, because angular-cli already does what we need (AOT + Webpack).

Currently we have to wrap angular-cli with gulp to remove hashes and unused files, it is silly job.

[FerGabPereira]

+1 to add this feature.

[shoagraw]

I found this working now, seems got added already with so many request :)
add --output-hashing none during build
media: only add hashes to files processed via [url|file]-loaders
bundles: only add hashes to the output bundles
all: add hashes to both media and bundles
So my build command looks like this:- _ng build --prod --output-hashing none_

[shoagraw]

I found this working now, seems got added already with so many request :)
add --output-hashing none during build
media: only add hashes to files processed via [url|file]-loaders
bundles: only add hashes to the output bundles
all: add hashes to both media and bundles
So my build command looks like this:- ng build --prod --output-hashing none

[kevindqc]

I need filenames that don't change but also would like to have a hash to invalidate cache. Is there a reason the hash can't be on the query string?

For example, this gets injected into my index.html:

<script type="text/javascript" src="inline.908517239e551bfc4e9b.bundle.js"></script>
<script type="text/javascript" src="polyfills.d2c49be8f78b2753060a.bundle.js"></script>
<script type="text/javascript" src="vendor.9f2dc5768d3730cb8f9d.bundle.js"></script>
<script type="text/javascript" src="main.6fa8c063126f9ead769a.bundle.js"></script>

How about:

<script type="text/javascript" src="inline.bundle.js?908517239e551bfc4e9b"></script>
<script type="text/javascript" src="polyfills.bundle.js?d2c49be8f78b2753060a"></script>
<script type="text/javascript" src="vendor.bundle.js?9f2dc5768d3730cb8f9d"></script>
<script type="text/javascript" src="main.bundle.js?6fa8c063126f9ead769a"></script>

[grizzm0]

@kevindqc With query string there's no guarantee that the files will be cached.

Squid for example used to have (I think it has changed) a default configuration that didn't cache dynamic content and query strings were considered to be dynamic content.

[timperez-weather]

Temporary solution...

In your package.json > scripts:
"build": "ng build --prod && mv dist/main.*.bundle.js dist/main.js && mv dist/vendor.*.bundle.js dist/vendor.js && mv dist/inline.*.bundle.js dist/inline.js && mv dist/polyfills.*.bundle.js dist/polyfills.js && cp -f src/index.dist-default.html dist/index.html"

The last operation of the build command above is to overwrite the index.html with something like "index.dist-default.html" in your src and set all script sources without the hash like this...

Example of scripts In your index replacement file (index.dist-default.html or whatever):
<script type="text/javascript" src="inline.js"></script>
<script type="text/javascript" src="polyfills.js"></script>
<script type="text/javascript" src="vendor.js"></script>
<script type="text/javascript" src="main.js"></script>

[lihuabest]

if you want build file like

first set build line like
ng build --prod --output-hashing none

second update webpack config,the file at node_module/@angular/cli/models/webpack-configs/brower.js
update HtmlWebpackPlugin config,
new HtmlWebpackPlugin({ ... hash: true // add }),

this is just i find...hopeful official solution

[dgecawich]

I tested the above solution and it works well, resulting in the following.

index.html
<script type="text/javascript" src="inline.bundle.js?b82bfbf37295902d0092"></script>
<script type="text/javascript" src="polyfills.bundle.js?b82bfbf37295902d0092"></script>
<script type="text/javascript" src="scripts.bundle.js?b82bfbf37295902d0092"></script>
<script type="text/javascript" src="styles.bundle.js?b82bfbf37295902d0092"></script>
<script type="text/javascript" src="vendor.bundle.js?b82bfbf37295902d0092"></script>
<script type="text/javascript" src="main.bundle.js?b82bfbf37295902d0092"></script>

IMHO, this solution provides the best of both worlds and end solution for many posters, as follows:
(1) ng build --prod --output-hashing none - deploy files with same name on each and every build which is desirable by many developers for SCM purposes (tracking, comparison, history etc.) and
(2) update webpack config to add hash query string in index.html - attaches a unique hash as a query string which, in most cases, will result in uniquely versioning your file in the browser cache so the browser reads the new version of the artifacts on each new deployment rather than reading it from cache.

However, it requires forking Angular CLI at the webpack config,the file at node_module/@angular/cli/models/webpack-configs/brower.js to add one configuration line to the new HtmlWebpackPlugin section (... ,hash: true // add }). To avoid a fork to Angular CLI, I would recommend a new option, to the effect of:

ng build --prod --output-hashing partial

where "partial" adds a hash query string but does not add a hash to files. The name of the option can be decided; having a configurable feature that blends both features above would avoid a fork, preserve SCM tracking of files, while also eliminate most caching issues, all of which are useful and seem to meet a requirement of a large population. Thank you.

[magnattic]

Any chance to reopen this issue for a solution like @dgecawich suggested? (move hash to query string) Or should we open a new issue?

I have a usecase that would need the same solution. A Piwik plugin tries to load the styles of our site at a later point but without a fixed filename it will already be gone. However, disabling the hashing completely will lead to trouble with the cache. Hash in the query string seems to have the best of both worlds.

[chrisj-skinner]

--output-hashing none works a treat. Nice that everyone on this post was notified and that it is now included in the docs. Oh wait, they weren't and it's not. I know - we'll add a great feature in that everyone was requesting but won't tell anyone or put it in the docs. Now that sounds like what devs would do... 👍

[yurart]

Thanks! It's a really useful feature

[abbymrs]

@lihuabest Is there a way to replace the hash number with a specified version number? Something like this:
<script type="text/javascript" src="main.bundle.js?version=1.2.0"></script>

[Vitzkrieg]

in angular.json

"configurations": {
            "production": {
                           ...
                           "outputHashing": "none",
                           ...
             }
}

[angular-automatic-lock-bot[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._}