Skip to content

No hash in name in production build #2774

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
fredrik-holmqvist opened this issue Oct 19, 2016 · 31 comments · Fixed by #3885
Closed

No hash in name in production build #2774

fredrik-holmqvist opened this issue Oct 19, 2016 · 31 comments · Fixed by #3885
Labels
P5 The team acknowledges the request but does not plan to address it, it remains open for discussion

Comments

@fredrik-holmqvist
Copy link

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
Copy link
Contributor

grizzm0 commented Oct 19, 2016

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
Copy link
Contributor

^ what @grizzm0 said 💃

@fredrik-holmqvist
Copy link
Author

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
Copy link
Contributor

grizzm0 commented Oct 24, 2016

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
Copy link
Author

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
Copy link
Contributor

grizzm0 commented Oct 24, 2016

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

@fredrik-holmqvist
Copy link
Author

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
Copy link
Contributor

@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
Copy link
Author

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
Copy link
Contributor

@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.

@filipesilva filipesilva added type: enhancement P5 The team acknowledges the request but does not plan to address it, it remains open for discussion labels Nov 3, 2016
@chouclee
Copy link

chouclee commented Nov 7, 2016

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
Copy link
Contributor

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

@filipesilva filipesilva reopened this Nov 21, 2016
@un33k
Copy link

un33k commented Dec 2, 2016

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
Copy link

un33k commented Dec 6, 2016

@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
Copy link

mmoravcik commented Dec 9, 2016

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
Copy link

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
Copy link

kemsky commented Jan 9, 2017

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
Copy link

+1 to add this feature.

@shoagraw
Copy link

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
Copy link

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
Copy link

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
Copy link
Contributor

grizzm0 commented Apr 26, 2017

@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
Copy link

timperez-weather commented Apr 27, 2017

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
Copy link

if you want build file like

<script type="text/javascript" src="inline.bundle.js?908517239e551bfc4e9b"></script>

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
Copy link

dgecawich commented Aug 1, 2017

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
Copy link

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
Copy link

chrisj-skinner commented Apr 30, 2018

--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
Copy link

yurart commented May 24, 2018

Thanks! It's a really useful feature

@abbymrs
Copy link

abbymrs commented Jun 28, 2018

@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
Copy link

in angular.json

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

@angular-automatic-lock-bot
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 9, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
P5 The team acknowledges the request but does not plan to address it, it remains open for discussion
Projects
None yet
Development

Successfully merging a pull request may close this issue.