You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is there a way I can build production css and js file without the random generated number at the file?
For example, every time I build I get something like this main.a31171f1.css and main.a31171f1.js. I need this because I want to be able to fix that in my index.html.
Yes, I'm not sure why you need to remove those "random generated number" (also, it is not random, it is a hash based on your file content, which is, as @tbillington explained, useful for caching)
Beside tbillington's solution, you can also eject or fork CRA and make your change in the config file (like this line is what cause the hash in the name of CSS file). Althought, I think tbillington's solution is best for this case.
Thanks, the reason is that because we use DFP and it takes about 15 min for DFP to change the HTML. So, we just upload the main.js and main.css to S3 and serve from there instead. Thanks for the suggestion I'll eject CRA and do that.
Instead of removing hashes and thus potentially breaking your website for people who have cached some of the files but not the others, could you merge the old and new build folders? Since the hashes are based on content, you won't have name clashes. Keep old files together with new files for a single deploy, then do the same for the next deploy. And you don't need to eject; just add your custom script to scripts section in package.json.
Just wanted to salt this discussion with my hash: I also need some hash-less filenames, because I digest the static files with Phoenix, which does the hashing itself. The asset-manifest doesn't work here, so maybe you should reconsider a option for hash-less filesnames.
Renaming is a workaround, but ... does CRA support Chunks? If yes, renaming would be painful.
There is some validity to needing to remove the content hashes, or at least have access to what they are after each file change. I've been making some chrome extensions with r-c-a and the only way I've found to include my scripts into my manifest.json is to either:
edit the hashes each time - obvs wouldn't do that
use another script to either find the hashes from the lfs and put them into my manifest.json
npm run eject and modify the build script to not use hashes (that's what I've been doing)
But now, I'm interested in adding an option to r-c-a to not append content hashes.
The other solution is to calculate the hashes on my own and modify my manifest.json file on each file change - but I'd need a parallel process with my own watch to do that when using npm start (because I'd like to avoind running npm run build each time I make a change. With chrome extensions, hashes have far less value from a web app since you have to reload your extension in chrome anyways on each file change. So right now, option 3 is still my best bet - but I don't like ejecting there's no real reason I've found to do so other than this.
One way I got around dealing with this issue and putting the output where I want is to just mv -f src/file-hash.js dest/file-what-i-want
in my npm scripts after the build. I don't know if this is the best way, but It seems to work for me and just a quick hacky suggestion
When you run build, a file called asset-manifest.json (if I recall correctly) appears in the build folder. It contains the list of all files. You can read it in a post build step and then do anything you like (such as use that info for rewriting Chrome extension manifest).
For using the asset-manifest, I would still need to set a watch on it if I intend to use r-c-a npm start right?
What I'm saying is, when I edit some code, and webpack runs and all my new code gets dumped into build/, I'd still need a way to trigger a change to my chrome manifest.json file - that would be that part that would read the new values in asset-manifest and use them accordingly.
The asset manifest only gets created on npm run build. There are no physical files created during npm start anyway, so there is nothing to copy. For a watching mode that writes to disk in development, please track #1070.
Using Mr. Abramov's mention of asset-manifest.json, I created this script a person could run if they use node.js:
constfs=require('fs');// Put manifest.json contents into an Objectletmanifest=JSON.parse(fs.readFileSync('build/manifest.json','utf8'));// Get hashes from asset-manifest.jsonconsthashes=JSON.parse(fs.readFileSync('build/asset-manifest.json','utf8'));// Update manifest with extracted hashesmanifest.content_scripts[0].css[0]=hashes['main.css'];manifest.content_scripts[0].js[0]=hashes['main.js'];// Write updated manifest.jsonfs.writeFileSync('build/manifest.json',JSON.stringify(manifest,null,2));
Something that I was able to do with React Rewired (https://github.com/timarney/react-app-rewired). I will say that if you are really overriding a lot in the future it might be worth ejecting.
// config-overrides.jsmodule.exports={webpack: function(config,env){if(env==="production"){//JS Overridesconfig.output.filename='static/js/[name].js';config.output.chunkFilename='static/js/[name].chunk.js';//CSS Overridesconfig.plugins[4].filename='static/css/[name].css';//Media and Assets Overridesconfig.module.rules[1].oneOf[0].options.name='static/media/[name].[ext]';config.module.rules[1].oneOf[3].options.name='static/media/[name].[ext]';}returnconfig;}};
This should take care of the hashes, mapping, and media/asset. Sadly with the way plugins are implemented in an array, I have to use fixed indexes. Also, if you do end up adding more plugins it could mess with those fixed indexes.
Activity
tbillington commentedon Nov 3, 2016
You can see here for what it is and why it is useful https://webpack.github.io/docs/long-term-caching.html.
You could edit your build script to run a shell script afterwards and rename them.
thien-do commentedon Nov 3, 2016
Yes, I'm not sure why you need to remove those "random generated number" (also, it is not random, it is a hash based on your file content, which is, as @tbillington explained, useful for caching)
Beside tbillington's solution, you can also eject or fork CRA and make your change in the config file (like this line is what cause the hash in the name of CSS file). Althought, I think tbillington's solution is best for this case.
noppanit commentedon Nov 3, 2016
Thanks, the reason is that because we use DFP and it takes about 15 min for DFP to change the HTML. So, we just upload the
main.js
andmain.css
to S3 and serve from there instead. Thanks for the suggestion I'll eject CRA and do that.tbillington commentedon Nov 4, 2016
@noppanit Just for posterity, my build looks like this
noppanit commentedon Nov 4, 2016
@tbillington Thanks! that's exactly what I ended doing.
gaearon commentedon Nov 4, 2016
Instead of removing hashes and thus potentially breaking your website for people who have cached some of the files but not the others, could you merge the old and new build folders? Since the hashes are based on content, you won't have name clashes. Keep old files together with new files for a single deploy, then do the same for the next deploy. And you don't need to eject; just add your custom script to
scripts
section inpackage.json
.noppanit commentedon Nov 5, 2016
Thanks a lot! I'll try that.
vseehausen commentedon Nov 6, 2016
Just wanted to salt this discussion with my hash: I also need some hash-less filenames, because I digest the static files with Phoenix, which does the hashing itself. The asset-manifest doesn't work here, so maybe you should reconsider a option for hash-less filesnames.
Renaming is a workaround, but ... does CRA support Chunks? If yes, renaming would be painful.
thien-do commentedon Nov 6, 2016
@Valentin-Seehausen: is this what you mean by "chunks"?
vseehausen commentedon Nov 6, 2016
Jap, code splitting. Ok, so CRA supports it secretly? :)
-> So renaming is not a long-term solution. How do I handle this hashing issue?
lasergoat commentedon Mar 6, 2017
@tbillington @dvkndn @Valentin-Seehausen @gaearon
Hey guys, I hate to dig up the past, but...
There is some validity to needing to remove the content hashes, or at least have access to what they are after each file change. I've been making some chrome extensions with r-c-a and the only way I've found to include my scripts into my
manifest.json
is to either:npm run eject
and modify the build script to not use hashes (that's what I've been doing)This way, my chrome extension can simply do:
But now, I'm interested in adding an option to r-c-a to not append content hashes.
The other solution is to calculate the hashes on my own and modify my
manifest.json
file on each file change - but I'd need a parallel process with my own watch to do that when usingnpm start
(because I'd like to avoind runningnpm run build
each time I make a change. With chrome extensions, hashes have far less value from a web app since you have to reload your extension in chrome anyways on each file change. So right now, option 3 is still my best bet - but I don't like ejecting there's no real reason I've found to do so other than this.danieldram commentedon Mar 6, 2017
One way I got around dealing with this issue and putting the output where I want is to just
mv -f src/file-hash.js dest/file-what-i-want
in my npm scripts after the build. I don't know if this is the best way, but It seems to work for me and just a quick hacky suggestion
gaearon commentedon Mar 6, 2017
When you run build, a file called
asset-manifest.json
(if I recall correctly) appears in the build folder. It contains the list of all files. You can read it in a post build step and then do anything you like (such as use that info for rewriting Chrome extension manifest).Hope this helps.
lasergoat commentedon Mar 6, 2017
@gaearon @danieldram thanks for the quick replies!
For using the asset-manifest, I would still need to set a watch on it if I intend to use r-c-a
npm start
right?What I'm saying is, when I edit some code, and webpack runs and all my new code gets dumped into build/, I'd still need a way to trigger a change to my chrome manifest.json file - that would be that part that would read the new values in asset-manifest and use them accordingly.
gaearon commentedon Mar 6, 2017
The asset manifest only gets created on
npm run build
. There are no physical files created duringnpm start
anyway, so there is nothing to copy. For a watching mode that writes to disk in development, please track #1070.viankakrisna commentedon Feb 21, 2018
@lasergoat you might be interested in #4014
agm1984 commentedon Mar 24, 2018
Using Mr. Abramov's mention of
asset-manifest.json
, I created this script a person could run if they use node.js:NateAGeek commentedon Jul 20, 2018
Something that I was able to do with React Rewired (https://github.com/timarney/react-app-rewired). I will say that if you are really overriding a lot in the future it might be worth ejecting.
This should take care of the hashes, mapping, and media/asset. Sadly with the way plugins are implemented in an array, I have to use fixed indexes. Also, if you do end up adding more plugins it could mess with those fixed indexes.