Unique identifier ng build --prod

[psaussure]

When compiling with ng build, I get standard file names:

chunk    {0} main.bundle.js, main.bundle.map (main) 107 kB {3} [initial] [rendered]
chunk    {1} styles.bundle.css, styles.bundle.map, styles.bundle.map (styles) 150 kB {4} [initial]
chunk    {2} scripts.bundle.js, scripts.bundle.map (scripts) 136 kB {4} [initial]
chunk    {3} vendor.bundle.js, vendor.bundle.map (vendor) 4.79 MB [initial]
chunk    {4} inline.bundle.js, inline.bundle.map (inline) 0 bytes [entry]

but with ng build --prod i get some identifiers added to file names.

chunk    {0} main.340157664918857603f7.bundle.js, main.340157664918857603f7.bundle.map (main) 106 kB {3} [initial] [rendered]
chunk    {1} styles.9b4687a185c2974d93c1.bundle.css, styles.9b4687a185c2974d93c1.bundle.map, styles.9b4687a185c2974d93c1.bundle.map (styles) 147 kB {4} [initial] [rendered]
chunk    {2} scripts.eb3f44fc5155c6a1c948.bundle.js, scripts.eb3f44fc5155c6a1c948.bundle.map (scripts) 136 kB {4} [initial] [rendered]
chunk    {3} vendor.fbab65b1f30d6a22e3c5.bundle.js, vendor.fbab65b1f30d6a22e3c5.bundle.map (vendor) 4.57 MB [initial] [rendered]
chunk    {4} inline.2a57c067d70b51f52b6f.bundle.js, inline.2a57c067d70b51f52b6f.bundle.map (inline) 0 bytes [entry] [rendered]

Are these identifiers always the same in a given app?
It it possible to change the behavior of prod build not to have these identifiers added to file name?

My own app is deeply intergrated with .NET project and my app loading is based on files without identifier. I don't want to have to edit my .NET view template in order to add at each build the unique identifier.

Side question: _prod is supposed to apply some tree-shaking, but as you can see on the logs pasted above, the vendor bundle is 4.79MB on normal build and 4.57MB on prod.
My app simply use basic routing, angularfire2 and http module. Is this size normal?

[celliott181]

These identifiers are added to prevent loading of old bundles from a cache. By removing them you risk users loading old bundles from their cache in the event you start serving a new build without different bundle names.

[psaussure]

Ok so I need to find a way, in my Index.cstml for example, to "guess" identifiers. Any idea?

[celliott181]

Well, you can be sure of most of the filename for all of them, and the identifiers are just hash strings. Sounds like time for regular expressions and/or a file map!

[psaussure]

Was afraid of that haha. Im quite unfamiliar with regex. Regex demon to fight!

[ersurajnegi]

Is there any way we can set the names for these files so that everytime it will generate the same file and we don't have to change anything in .cshtml file

[celliott181]

@ersurajnegi Let me reiterate: These hashes are there to prevent a browser from accidentally loading a cached and out of date version of your application. By forcing them to all be the same name consistently across builds you have a high risk of users loading the wrong bundle and performing actions with undefined behavior.

The regex to match these isn't too difficult. /(main|styles|scripts|vendor|inline).*.bundle.(map|js|css)/g will match all eight files.

[hansl]

@psaussure If you don't need the hashes (and know how to deal with caches), use the following BASH command (from your project root):

for src in dist/*.bundle.*; do
  dest=$(echo $src | sed "s/\\.[0-9a-z]*\\.bundle/.bundle/")
  mv $src $dest
done

That will remove all the hashes in the dist/ folder.

Closing this as fixed (per this comment and discussion above).

[kevindqc]

Is the hash in the filename really necessary though?

I have the same problem... I'm using WiX to deploy my angular application along with a windows service and a few other things. The problem is that deployed files in WiX need to be explicitly defined in an XML document like so:

<Component Id="app.bundle.js" Guid="{88FF7F86-D8E1-42F0-9EEC-365342AE57DB}">
  <File Id="app.bundle.js" KeyPath="yes" Source="$(var.TargetDir)..\dist\app.bundle.js" />
</Component>
<Component Id="polyfills.bundle.js" Guid="{CB3898F1-E382-4CDD-91ED-D4E0D52332D2}">
  <File Id="polyfills.bundle.js" KeyPath="yes" Source="$(var.TargetDir)..\dist\polyfills.bundle.js" />
</Component>
<Component Id="styles.bundle.js" Guid="{B4E38316-CADA-4CE9-99EF-C019F6B2C3A7}">
  <File Id="styles.bundle.js" KeyPath="yes" Source="$(var.TargetDir)..\dist\styles.bundle.js" />
</Component>
<Component Id="vendor.bundle.js" Guid="{5A2393C4-FB11-43F6-A832-E047525C4824}">
  <File Id="vendor.bundle.js" KeyPath="yes" Source="$(var.TargetDir)..\dist\vendor.bundle.js" />
</Component>

To make sure no stale javascript/css/etc are loaded, that's what I currently have in my not-angular-cli-project-yet in the webpack config:

output: { filename: '[name].bundle.js?[hash]' }

The generated index.html would reference these files like:
<script type="text/javascript" src="app.bundle.js?624a95c5b0a79cdcc871">

[atul121001]

@hansl

for src in dist/.bundle.; do
dest=$(echo $src | sed "s/\.[0-9a-z]*\.bundle/.bundle/")
mv $src $dest
done

This removes the identifiers from the bundle from the dist folder but the path also get change in index.html too .. how can we manipulate in that

But it also updates the path with that identifiers in index.html file too

[agermanique]

you can also do that : #3885

but for a project I'm working on (and optimizing) I would need to remove hash only for the scripts/libraries lazy loaded as I'm only able to load them by adding a script element with the src attribute being "myscript.bundle.js". Unless someone knows a way to dynamically get those hash to get the right name, I'll have to remove the hash for those scripts/libraries.

[Hariharan2808]

We can avoid hashing the filename during build using ng build --output-hashing. you can refer
#3885

[k11k2]

The regex to match these isn't too difficult. /(main|styles|scripts|vendor|inline).*.bundle.(map|js|css)/g will match all eight files.

@gelliott181 I'm using aspnet core new angular 5 template, I'm getting multiple bundles of same name
like

inline.*.bundle.js
inline.*.bundle.js
inline.*.bundle.js

unable to figure out which one to pick.

[Hariharan2808]

Kindly check the index.html of your application. The correct file will be specified in the src of the script tag. On Feb 23, 2018 5:24 PM, "AlwaysAbhl001" <notifications@github.com> wrote: The regex to match these isn't too difficult. /(main|styles|scripts|vendor| inline).*.bundle.(map|js|css)/g will match all eight files. @gelliott181 <https://github.com/gelliott181> I'm using aspnet core new angular 5 template, I'm getting multiple bundles of same name like inline.*.bundle.js inline.*.bundle.js inline.*.bundle.js unable to figure out which one to pick. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3769 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AhQ9mZcpKhAQen1Px7SpGumy4TO2rYJhks5tXqb0gaJpZM4LXGLN> .

[k11k2]

We can avoid hashing the filename during build using ng build --output-hashing. you can refer
#3885

but by doing this we don't face any cache problems like getting old one ? cause we do all these in continues integration rather then separately generating prod dist files manually so having concern on caches.

[clouseryan]

I was able to solve this by using ng build --prod --named-chunks. hope that helps someone looking for this

[gopikl]

ng build --prod --output-hashing=none is the right thing to do here.

Refer to https://stackoverflow.com/questions/39718803/custom-generated-filename-with-angular-cli

[phil123456]

the hashes are useless, we keep having customers complaining about non working functionalities while CTRL+F5 solves the issue every time

the only way we could fix this was to eject angluar cli project and add a build number or a date manualy to each filename...then you cant use ng command on the project anymore

this just s@#ks

please add a feature so we can add a custom string to the hash, or replace the hash at all, from the command line

[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.}